EPICS Controls Argonne National Laboratory

Experimental Physics and
Industrial Control System

1994  1995  1996  1997  1998  1999  2000  2001  2002  2003  2004  2005  2006  2007  <20082009  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  <20082009  2010  2011  2012  2013  2014  2015  2016  2017  2018  2019  2020  2021  2022  2023  2024 
<== Date ==> <== Thread ==>

Subject: Re: Atomic "check and reserve" question
From: Andrew Johnson <[email protected]>
To: "Chestnut, Ronald P." <[email protected]>
Cc: EPICS tech-talk <[email protected]>
Date: Thu, 05 Jun 2008 11:44:23 -0500
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

Navigate by Date:
Prev: procServ soft IOC server - V2.3.0 released Ralph Lange
Next: Channel Archiver - recovering from power outage Devin Bougie
Index: 1994  1995  1996  1997  1998  1999  2000  2001  2002  2003  2004  2005  2006  2007  <20082009  2010  2011  2012  2013  2014  2015  2016  2017  2018  2019  2020  2021  2022  2023  2024 
Navigate by Thread:
Prev: Re: procServ soft IOC server - V2.3.0 released Steve Lewis
Next: Channel Archiver - recovering from power outage Devin Bougie
Index: 1994  1995  1996  1997  1998  1999  2000  2001  2002  2003  2004  2005  2006  2007  <20082009  2010  2011  2012  2013  2014  2015  2016  2017  2018  2019  2020  2021  2022  2023  2024 
ANJ, 02 Sep 2010 Valid HTML 4.01! · Home · News · About · Base · Modules · Extensions · Distributions · Download ·
· Search · EPICS V4 · IRMIS · Talk · Bugs · Documents · Links · Licensing ·