Till,
I think the following is the only issue still bothering you. Is this true?
Till Straumann wrote:
>
> 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:
>
> * record A processing (i.e. in the context of a low prio scanning task)
> starts
> writing a field.
> * record B processing starts (in the context of a high prio task)
> preempting
> the processing of record A. record B processing calls
> dbGetLink() trying to read just the field A is currently writing.
> Hence B will get only the partially written value!
> * record A completes writing the field and terminates processing.
>
> It is indeed very simple to observe this race condition. I created two
> stringin
> records, A and B. B is scanned `.1 second', has its INP field set to
> "A NPP" and is using the devSiSoft device. A is scanned less frequently and
> has a device support module which (artificially slowly) modifies its value
> field.
> Observing B shows that the described race condition occasionally is met.
All records linked together are put in the same lock set (for the reason
discussed in the App Dev Guide) EXCEPT for scalar NPP NMS input links.
The exception was made just to prevent locks sets from becoming big just because
one record of a lock set just want some relatively recent value from another
record.
DBF_STRING should not have been included because strcpy is certainly not an
atomic operation. I can also believe that on some architecture/compiler
implementations copying some other types (such as doubles) may not be atomic.
In defense of the decision please note that when lock sets were first
implemented
1) vxWorks did not support recursive locking (semMcreate)
2) iocCore did not support the CA, CP, CPP options.
Because of 1) it was not possible to have a task lock the same resource more
than once. If this had been available implementation would have been much
easier.
Because 2) now exists it may be a good idea to get rid of the input NPP NMS
exception and treat all links the same when determining lock sets, i.e. all
records linked via database links are put in the same lock set.
Comments?
Marty Kraimer
- Replies:
- Re: database race condition? Till Straumann
- References:
- database race condition? Till Straumann
- Navigate by Date:
- Prev:
Interrupt message jlin
- Next:
Scan Record Mark J. Ryan
- 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: database race condition? Till Straumann
- Next:
Re: database race condition? Till Straumann
- 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
|