EPICS Controls Argonne National Laboratory

Experimental Physics and
Industrial Control System

1994  1995  1996  1997  <19981999  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  Index 1994  1995  1996  1997  <19981999  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 
<== Date ==> <== Thread ==>

Subject: RE: synchronizing client requests & completions
From: Jeff Hill <[email protected]>
To: "'Alan K Biocca'" <[email protected]>
Cc: Marty Kraimer <[email protected]>, EPICS Techtalk <[email protected]>
Date: Thu, 12 Mar 1998 10:55:07 -0700
Alan,

> 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.
> 

Note that ca_put_callback() will not inform your client application
of put request completion until after all record processing (including links and 
asynchronous record processing) initiated by the CA put request 
have completed. If your record is asynchronous then the PACT field 
will be TRUE when the record is busy and FALSE once its request to 
a slow device has completed. Note that most of the high level CA client 
lib wrappers such CA synchronization groups and ezca use 
ca_put_callback() for put operations. 

It sounds like your immediate problem is that you need to guarantee 
that a certain set of request have completed before initiating another 
set of requests. It appears that ca_put_callback() will provide proper
synchronization without resorting to ugly and complex code in your 
client side application.

> 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
> 
> 


Jeff

Navigate by Date:
Prev: RE: Proposal for boosted Symb device support Jeff Hill
Next: Re: synchronizing client requests & completions William Lupton
Index: 1994  1995  1996  1997  <19981999  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 Tim Mooney
Next: Re: synchronizing client requests & completions William Lupton
Index: 1994  1995  1996  1997  <19981999  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 
ANJ, 10 Aug 2010 Valid HTML 4.01! · Home · News · About · Base · Modules · Extensions · Distributions · Download ·
· Search · EPICS V4 · IRMIS · Talk · Bugs · Documents · Links · Licensing ·