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 | 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 |
<== Date ==> | <== Thread ==> |
---|
Subject: | database race condition? |
From: | Till Straumann <[email protected]> |
To: | [email protected] |
Date: | Thu, 18 Mar 1999 15:07:16 +0100 |
FLNK
Record 1 --------->
Record 2
^
|
|
|
------------------------
dbGetField()
Of course, the deadlock occurred because Record1 processing had
not finished yet at the time the FLNK was processed, leaving Record1
locked when dbGetField() also tried to lock Record1, hence the deadlock.
(Both records are not necessarily scanned by the same task)
Nevertheless, I remembered a very similar constellation to work well
FLNK
Record1 -------->
Record2
^
|
|
|
---------------------
INP NPP
Here, Record2 obtains the value by dbGetLink() and no deadlock occurs.
Studying the source, I was surprised to learn that dbGetLink() (calling
dbGet)
not only does no record locking, but EPICS not seeming to implement
something like a `field read/write access mutex'. A task reading a
database
link (using dbGetLink()) may therefore read a tampered value from a
record
according to the following race condition:
Did I miss something? Wouldn't some finer grained locking than locking
a whole
scanLock set make sense to prevent this kind of race condition?
Best regards.
Till Straumann (PTB/Bessy II, Berlin)