Request for suggestions for asynPortDriver locking implementation

[Érico Nogueira Rolim via Tech-talk <tech-talk at aps.anl.gov>]

Hey folks!

I opened an issue in asyn [1] asking about the locking scheme of
asynPortDriver, where all functions are called with the driver lock
(which is currently different from the port lock) held. This has a
noticeable impact on some areaDetectors drivers, mainly those
"emulating" multiple acquisitions in software, which, in order to
emulate acquirePeriod, relinquish the lock, wait for a stopEvent with a
timeout equal to acquirePeriod-elapsedTime, and then re-grab the lock:
they need to clamp acquirePeriod-elapsedTime to a minimum value
(ADSimDetector uses 1e-5 seconds) to guarantee that there's enough time
for the thread running writeInt32 (with function=ADAcquire and value=0)
to grab the lock and send a stop event.

I would like to avoid hardcoding an empirical minimum delay, since it
depends on multiple system conditions, and won't be perfectly reliable.
My initial suggestion for dealing with this was adding a flag to
asynPortDriver which would allow the class methods to be called without
holding the lock (or overriding the asynInterface function pointers, to
override specific functions instead of all methods), and making drivers
deal with this. However, folks in the AreaDetector collaboration meeting
disliked this solution, and suggested alternatives:

- simply keeping this minimum value which currently works;

- Mark Rivers suggested moving from a separate driver lock to using the
port lock via queueLockPort, which should avoid this issue (this
solution keeps the system functional, but I haven't been able to test
the performance impact under high contention yet);

- Mark also suggested inquiring in tech-talk if folks had experience
with some other locking primitive which provided "fair-locking"
(guaranteeing that threads can grab the lock in approximately FIFO
order), allowing us to avoid redesigning how the implementation deals
with locking.

I would be grateful if you could weigh in on the discussion, so we can
reach the best solution.


A note for anyone wishing to reproduce the behavior in order to better
understand it: you need a driver which calls epicsEventWaitWithTimeout
with a timeout <= 0, and you should probably run it on Windows. The
usage of condvars in the POSIX implementation (used on Linux) makes this
behavior of missing a stop event much less likely.


[1] https:// github.com/epics-modules/asyn/issues/2271


Cheers,

Érico


Aviso Legal: Esta mensagem e seus anexos podem conter informações confidenciais e/ou de uso restrito. Observe atentamente seu conteúdo e considere eventual consulta ao remetente antes de copiá-la, divulgá-la ou distribuí-la. Se você recebeu esta mensagem por engano, por favor avise o remetente e apague-a imediatamente.

Disclaimer: This email and its attachments may contain confidential and/or privileged information. Observe its content carefully and consider possible querying to the sender before copying, disclosing or distributing it. If you have received this email by mistake, please notify the sender and delete it immediately.