Experimental Physics and
Industrial Control System

Eric Norum <[email protected]> · Wed, 10 Oct 2007 16:41:15 -0500

On Oct 10, 2007, at 4:36 PM, Mark Rivers wrote:
Hi Heinrich,
Thanks for finding this problem and suggesting one solution.
A recap of the problem for those who have not followed it: if 2 or
more

interrupts come in rapid sucession to asyn device support, it can
result

in the the device support routine (called from scanIoRequest record

processing) calling the drivers read() routine when it should not
do so.
It seems like there are 2 possible solutions.
Solution 1) (basically Heinrich's suggestion):

Ignore callbacks that happen before the previous callback has finished

executing processCommon in asyn device support. The right way to do

this would be to add a mutex to protect access to the gotValue and
data

fields. This has the disadvantage of missing data when interrupts
come

close together, even if the system could handle the average interrupt

rate.
Solution 2).

Rather than have the callback routine call scanIoRequest, have it

directly call dbScanLock and pr->process. This way the callback and

record processing are done in the same thread, and there is no need
for

a mutex. The consequences of this solution are:
- There is no missed data, as long as the system can keep up with the
average data rate.
- The callback routine must not be called at interrupt level, because
the record will not be processed in a separate callback thread.
However, the asyn documentation is already explicit that the
pasynManager->interruptStart routine cannot be called at interrupt
level, so the callback routine cannot be running at interrupt level.
- The asyn driver must have already created a thread that the callback
will run in.  Under the new scheme this callback thread will not just
copy the data to the device support private, set a flag and call
scanIoRequest, but it will actually process the record.  It will also
process any records that this record forward links to.  This could
require more stack, and will take somewhat more time.

More time in the callback thread, but presumably less time overall
since the overhead of queueing a request and context switch to/from
the scanIO thread would be eliminated.

- The driver must implement some data queuing mechanism if data is not

to be lost. For example, my ip330 ADC driver uses an
epicsMessageQueue

to send the ADC data from the interrupt routine to the driver thread

that does callbacks to device support. This queue must be large
enough

to buffer the data when interrupts come close together and the
callback

task is busy processing records.
I am leaning towards solution 2), but I would like to hear comments
from

those who have an opinion. Note that the solution must be applied to

all of the asyn device support, not just the asynInt32Array device

support Heinrich was working with.

Solution 2 sounds the best to me.
--
Eric Norum <[email protected]>
Advanced Photon Source
Argonne National Laboratory
(630) 252-4793

Experimental Physics and Industrial Control System

Experimental Physics and
Industrial Control System