Re: Understanding ASYN_CANBLOCK

[Mark Rivers via Tech-talk <tech-talk at aps.anl.gov>]

Hi Marco,

If you have not already done so you should read the documentation here:

https://epics-modules.github.io/asyn/asynDriver.html#overview-of-queuing

You should always use ASYN_CANBLOCK for any driver which takes more than a few 10s of microseconds to complete an I/O request from device support.  If you do not use ASYN_CANBLOCK then the thread that calls you driver will be blocked until the I/O operation is complete.  This includes the scan tasks (1 second, 2 second, etc.), channel access server threads, etc.

If you are seeing freezing when you use ASYN_CANBLOCK then either you are starved for CPU (what does "top" show?) or something is wrong.  EPICS areaDetector drivers and plugins all use ASYN_CANBLOCK and they do thousands of callbacks to device support per second with no problem with performance.

Can you describe the driver and the number of I/O operations per second in more detail?

One way to reduce CPU is to write a thread in your driver that reads all of the parameters.  The records associated with those parameters have SCAN=I/O Intr.  When your driver does callParamCallbacks() only the parameters that have changed will have their records process.  If most parameters only change infrequently that can drastically reduce the amount of record processing.

Mark

---

From: Tech-talk <tech-talk-bounces at aps.anl.gov> on behalf of Marco Filho via Tech-talk <tech-talk at aps.anl.gov>
Sent: Thursday, January 30, 2025 4:02 PM
To: tech-talk at aps.anl.gov <tech-talk at aps.anl.gov>
Subject: Understanding ASYN_CANBLOCK

 

Hi all. I'm writing this e-mail to ask for help understanding ASYN_CANBLOCK.

I have an asyn driver that communicates via a thread-safe API with the hardware. It tries to read thousands of parameters and I noticed that the IOC was freezing periodically as I added more parameters to be scanned.

I also noticed that reducing the SCAN time from 1 second to 5 seems to make the IOC shell freeze every couple of seconds or so (instead of freezing constantly), and guessed - just a guess - that this could be due to asyn trying to scan all parameters at once, no matter the period of 5 seconds between each reading.

Searching for a way to distribute the readings in time and reading the documentation, I found ASYN_CANBLOCK, which seems to create a separate thread for managing the queue requests:

"If queueRequest is called for a port that can block the request is queued to a thread dedicated to the port."

I expected then that putting the ASYN_CANBLOCK flag in the driver constructor would solve my problem, but to my surprise the behavior was the opposite: I found out that the constructor was already using this flag:

asynPortDriver(portName, 1,
      asynInt8ArrayMask | asynInt32Mask | asynInt32ArrayMask | asynInt64Mask | asynFloat64Mask | asynOctetMask | asynDrvUserMask,          // Interfaces that we implement
      asynInt8ArrayMask | asynInt32Mask | asynInt32ArrayMask | asynInt64Mask | asynFloat64Mask | asynOctetMask,       // Interfaces that do callbacks
      ASYN_MULTIDEVICE | ASYN_CANBLOCK, 1, /* ASYN_CANBLOCK=1, ASYN_MULTIDEVICE=1, autoConnect=1 */
      0, 0),  /* Default priority and stack size */

And removing the flag caused the OPI and shell to not freeze. By visually and manually inspecting I also have the feeling that the parameters are being properly scanned and that I'm not leaving anything behind.

The question is: by removing ASYN_CANBLOCK am I actually distributing the readings in time or am I doing something else? Are the requests actually being executed in parallel?

Thanks for any elucidations,

Marco