Re: Atomic "check and reserve" question

[Andrew Johnson <anj@aps.anl.gov>]

Hi Ron,

(CC to tech-talk because I believe this particular technique is new...)

> > How do you implement a semaphore around a unique PV "set of 
> > resources", so that users don't overwrite data (for example), while 
> > some processing is occuring? Using a status PV, there is still a gap 
> > between checking and setting, of course.

It is possible to create a simple semaphore using a single ao, bo or 
longout record as follows:

record(ao,"${NAME}") {
    field(OUT,"${NAME}.DISP")
}

When the DISP field is non-zero it disables all CA puts to any other 
field of the record (but it is always possible to write to the DISP 
field, access security permitting of course).  A client wanting to take 
the semaphore uses ca_put_callback() to put a 1 to the VAL field of the 
record, which causes the DISP field to get set.  If another client now 
tries to take the semaphore its ca_put_callback() will be rejected, thus 
the second client knows that someone else has reserved the resource. 
When the first client has finished it puts a zero to the DISP field, 
which allows another client to take the semaphore.

If the second client had put a ca_monitor on the DISP field of the 
record, it would know when the first has finished and can thus when to 
attempt to take it again.  It is possible to add extra features to this 
with additional records, such as a BI that shows the current Free/Owned 
state of the semaphore (use a .CP link to monitor the DISP field of the 
first record) and even who currently owns it, but I'll leave those as an 
exercise to the student.

I believe it is currently impossible for a sequence program to detect a 
ca_put_callback() rejection, thus you can't take a semaphore from a 
sequence program, and DISP does not stop a database link from writing to 
the record either, so the semaphore is strictly for use by CA client 
programs, which *must* use ca_put_callback() and wait for the callback.

Needless to say this relies on all your clients to cooperate by claiming 
the relevant semaphore before using the resources it protects.  This 
means that a general-purpose tool like MEDM will always be able to 
bypass the semaphore protection (that is both good and bad).

At the APS we use a custom record type called the runcontrol record 
instead, which has libraries available in both C and tcl that implement 
the client side of the semaphore and call CA to talk to the record. 
After claiming ownership, the record requires the client to periodically 
ping the record in order to keep ownership of the resource; if it stops 
pinging before release, the runcontrol record goes into an alarm state 
which requires a deliberate manual intervention to clear.

> > The sequence of events is:
> >
> > (resources [PVs] all live on the IOC)
> >
> > Check for resource availabliity from Linux
> > Reserve resource from Linux
> > Prepare data buffer (CAPUT byte array PV from Linux) 
> > Signal IOC to proceed with data from Linux
> > Execute a process (few tenths of second max)
> > Prepare return data buffer (different byte array PV) in IOC
> > Signal Linux process that data are ready
> > Have your way with the data in Linux
> > Unreserve resource from Linux

That looks pretty much as I would expect.  You're welcome to a copy of 
our runcontrol record and its libraries if you want to look at it, but 
the above semaphore technique may be sufficient for your needs.

- Andrew
--
Talk is cheap. Show me the code. -- Linus Torvalds