Experimental Physics and Industrial Control System
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
<2008>
2009
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
<2008>
2009
2010
2011
2012
2013
2014
2015
2016
2017
2018
2019
2020
2021
2022
2023
2024