Experimental Physics and
Industrial Control System

Marty Kraimer <[email protected]> · Fri, 19 Mar 1999 08:42:40 -0600

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

Experimental Physics and Industrial Control System

Experimental Physics and
Industrial Control System