Experimental Physics and Industrial Control System
Yes, this is a bug that was reported to me recently. I've attached a message with the fix, which will be in the next release of asyn.
Mark
-----Original Message-----
From: Florian Feldbauer [mailto:[email protected]]
Sent: Wednesday, November 21, 2012 7:47 AM
To: EPICS Tech Talk
Cc: Mark Rivers
Subject: asynPortDriver epicsMutex error
Hey all,
I have written an asynPortDriver for one of my devices.
The device sends 8 different values in one message, so I do something
like this in my readInt32/readUInt32Digital
methods:
int function = pasynUser->reason;
if ( function == P_value0 ) {
SyncIO->writeRead(...);
setIntegerParam( P_value0, data[0], mask );
setIntegerParam( P_value1, data[1], mask );
...
callParamCallbacks()
}
getIntegerParam( function, value );
In my db file the record reading the first parameter is passively
scanned, while the other 7 have SCAN="I/O Intr".
I have 7 groups of parameters. 6 of them are of type asynInt32 and the
last one of type asynUInt32Digital.
For the asynInt32 parameters everything works fine. But when I try to
read the asynUInt32Digital I get the
following error:
epicsMutex pthread_mutex_unlock failed: error Operation not permitted
epicsMutexOsdUnlockThread vme001 (0x1912a18) can't proceed, suspending.
Thread vme001 (0x1912a18) suspended
vme001 is the name of my asynPortDriver.
Any idea what can cause this error?
Best regards
Florian
--
----------------------------------------
| Dr. Florian Feldbauer |
| |
| Institut für Kernphysik |
| Johannes Gutenberg-Universität Mainz |
| Johann-Joachim-Becher-Weg 45 |
| D-55128 Mainz |
| |
| Office: 01/217 |
| Phone: (+49)6131 / 39-25829 |
----------------------------------------
--- Begin Message ---
Hi Mark,
I've just been rolling out EPICS 3.14.12 & asyn 4-20 here at ANU and I
wanted to report a small but serious bug.
In asyn/devEpics/devAsynUInt32Digital.c the function
interruptCallbackInput() contains an epicsMutexUnlock() with no
corresponding epicsMutexLock().
The fix seems to be adding a single line to lock the mutex (I assume
the ring buffer does need to be accessed via the mutex):
@@ -395,6 +395,7 @@
* Instead we just return. There will then be nothing in the ring
buffer, so the first
* read will do a read from the driver, which should be OK. */
if (!interruptAccept) return;
+ epicsMutexLock(pPvt->mutexId);
I did a quick audit and couldn't see anywhere else that mutex access
was unbalanced.
Thanks very much for your work on asyn, btw. asynPortDriver is a
wonderful tool to have!
I'm hoping to have some time to test the new I/O Intr alarm setting
features as well now. Hopefully, spare time permitting. :)
Regards,
Angus
--
Angus Gratton, Computer Control Specialist
ANU Department of Nuclear Physics
(02) 6125 2091
--- End Message ---
- Navigate by Date:
- Prev:
Re: channel archiver on 64 bit? Re: archive data server Michael Davidsaver
- Next:
caRepeater object code not cross-compiled in R3.14.12.2 Rod Nussbaumer
- 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
- Navigate by Thread:
- Prev:
Re: EPICS on SL6.x Andrew Johnson
- Next:
caRepeater object code not cross-compiled in R3.14.12.2 Rod Nussbaumer
- 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