EPICS Home

Experimental Physics and Industrial Control System


 
1994  1995  1996  1997  1998  1999  2000  2001  2002  2003  2004  2005  2006  2007  2008  2009  2010  2011  <20122013  2014  2015  2016  2017  2018  2019  2020  2021  2022  2023  2024  Index 1994  1995  1996  1997  1998  1999  2000  2001  2002  2003  2004  2005  2006  2007  2008  2009  2010  2011  <20122013  2014  2015  2016  2017  2018  2019  2020  2021  2022  2023  2024 
<== Date ==> <== Thread ==>

Subject: RE: asynPortDriver epicsMutex error
From: Mark Rivers <[email protected]>
To: "'Florian Feldbauer'" <[email protected]>, EPICS Tech Talk <[email protected]>
Date: Wed, 21 Nov 2012 16:53:17 +0000
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 ---
Subject: Mutex bug in asyn 4-20 uint32digital callbacks
From: Angus Gratton <[email protected]>
To: Mark Rivers <[email protected]>
Date: Tue, 30 Oct 2012 02:30:26 +0000
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  <20122013  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  <20122013  2014  2015  2016  2017  2018  2019  2020  2021  2022  2023  2024