| 1994 1995 1996 1997 1998 1999 2000 2001 2002 2003 2004 2005 2006 2007 2008 2009 2010 2011 2012 2013 2014 2015 2016 2017 2018 2019 2020 2021 2022 2023 <2024> 2025 | Index | 1994 1995 1996 1997 1998 1999 2000 2001 2002 2003 2004 2005 2006 2007 2008 2009 2010 2011 2012 2013 2014 2015 2016 2017 2018 2019 2020 2021 2022 2023 <2024> 2025 |
| <== Date ==> | <== Thread ==> |
|---|
| Subject: | RE: areaDetector driver unlock/lock for doCallbacksGenericPointer() |
| From: | Mark Rivers via Tech-talk <tech-talk at aps.anl.gov> |
| To: | "Pearson, Matthew" <pearsonmr at ornl.gov> |
| Cc: | "tech-talk at aps.anl.gov" <tech-talk at aps.anl.gov> |
| Date: | Thu, 1 Aug 2024 22:13:49 +0000 |
|
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 at ornl.gov>
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 |