If I can separate myself from GANTT charts for a few minutes, I have a
question for the group. From time to time we struggle with request
synchronization between EPICS and other systems. A workstation-based
program scanning EPICS controlled subsystems has difficulty staying
correctly synchronized with variable-time processes. Solutions are
nontrivial and unsatisfying. (read ugly and complex)..
How to do this without unnecessary complexity in the client programs?
How do folks do this?
Are they happy with it?
We did some brainstorming and came up with one solution that looks good (to
us). I'll go get my nomex on and include the proposal below if anyone would
like to comment. Is it implementable? Is it worthwhile? Is there a
simpler/better approach here?
Thanks for your comments,
Alan Biocca
Advanced Light Source Controls
Request Synchronization Record (potentially proposed 3/11/98)
This record is designed to synchronize requests to (potentially) slow
processes by programs that need precise interactions. A good example of
this is a remote experimental scan program that needs to adjust a number of
parameters across networked servers and accurately determine that all
activities are completed before initiating a data collection activity,
repeating this cycle thousands of times per experiment.
The essence of the mechanism needed is a state transition from "ready" to
"busy" synchronously as the request is posted so that subsequent state
queries cannot temporarily see a "ready" and be misled. Multi-record
solutions tend to produce race windows and get out of synchronization.
Usage
A control program does a put to the val field followed by gets on the busy
field. The put causes processing and sets the BUSY field to go
synchronously true until the asynchronous process explicitly sets the
completion input field. The processing of the BUSY field increments the
completion count and clears the BUSY field.
The control program is guaranteed that it will not see a false NOT BUSY
after doing a put on the record. It can thus believe the returned state of
BUSY and not have to do complex timeouts, etc to insure synchronization.
Fields
VAL - request value
OUT - out link to put val to
BUSY - boolean set synchronously when put to val occurred
cleared by processing when completion processed
CMPL - completion input
CVAL - current value - optional field that reflects the actual current value
of the system while it is changing
CCNT - completion count - increments when completion processed
DONE - optional boolean complement of BUSY for client convenience
- Navigate by Date:
- Prev:
Re: SNC crashes William Lupton
- Next:
Re: EPICS experiences witn M68060 boards Alan K Biocca
- 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: synchronizing client requests & completions Peregrine M. McGehee
- Next:
Re: synchronizing client requests & completions Peregrine M. McGehee
- 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
|