RE: areaDetector driver unlock/lock for doCallbacksGenericPointer()

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

Hi Matt,

 

Thanks for point that out.  In 2017 I removed the unlock() / lock() operations surrounding the call to doCallbacksGenericPointer().  It was added at some point in the past because of a deadlock I had observed, but I think that was really some other problem.  I have fixed the documentation.

 

Mark

 

 

From: Pearson, Matthew <pearsonmr@ornl.gov>
Sent: Thursday, August 1, 2024 10:17 AM
To: Mark Rivers <rivers@cars.uchicago.edu>
Cc: tech-talk@aps.anl.gov
Subject: areaDetector driver unlock/lock for doCallbacksGenericPointer()

 

Hi Mark,

 

In the areaDetector driver documentation it states this, for passing NDArray objects to registered plugins:

 

Call doCallbacksGenericPointer() so that registered clients can get the values of the new arrays. Drivers must release their mutex by calling this->unlock() before they call doCallbacksGenericPointer(), or a deadlock can occur if the plugin makes a call to one of the driver functions.

 

It seems to make sense, but wouldn’t that be an odd design to have a plugin call a driver function?

 

Most drivers seem to hold the mutex while calling doCallbacksGenericPointer (at least all the ones I just checked).

 

Cheers,

Matt