Lock object

Hello,

I'm working on a plugin for an I/O card, and it is based on the EasyDAQ one.
Is it possible to have an explanation regarding the lock object used in the deviceStartComm() and deviceStopComm() methods ? I know the utility of a lock object in an multi-thread environment, but I would like to understand in this specific case what is its role ?
Thanks.

Julien

[matt (support)]

Hi Julien,

Code: Select all

if someLock.acquire(blockIfBusy):
   try:
      # code that you never want to run concurrently
   finally:
      someLock.release()

Multiple threads are used in the EasyDAQ plugin and we want to make sure that two threads don't try to call deviceStartComm() or deviceStopComm() at the same time, especially with the same device instance argument. That is, the result would be unpredictable (and likely cause a runtime error) if one thread tried to call deviceStopComm() while deviceStartComm() is also processing the startup of the same device. I have a vague recollection that there was an EasyDAQ bug reported a long time ago and I traced it to being a concurrency issue, so I added the locking semaphore to prevent it.

OK thanks for the explanation, it's clear.
One more question : in handleCommException() you call deviceStopComm() with blockIfBusy=False.
When deviceStopComm() start, if an other device is starting through deviceStartComm(), the lock will be blocked, and deviceStopComm() will finish without doing anything, and particularly without deleting the device thread. And during the next start, it will not start because a thread already exists (at least a thread is defined in commThreads.
Is it right ?

Julien

[matt (support)]

I think handleCommException() should be passing blockIfBusy=True to deviceStopComm() to avoid the problem you described. I'll be changing it in the next release. Thanks.

You're welcome.
It was easy for me as I had this specific case with my own plugin.