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
<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 Tim Mooney
- Next:
Re: synchronizing client requests & completions William Lupton
- 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
|