Benjamin Franksen wrote:
Hmmm. It depends of course on how much is deemed "significant runtime
overhead". I imagine a solution along the following lines: All puts that
occur during asynch processing (i.e. target record's PACT==TRUE) are
redirected (by dbPut) into a queue (linked list or cicular buffer or
some such thing), where pairs consisting of {field address, new value}
are stored. Only when the record completes processing, the puts stored
in this list actally happen. After that eventual re-processing is done.
The advantage is that for the 'normal' situation (either PACT==FALSE or
dbScanLock is active) the only additional overhead is the check for PACT
and the check for an empty queue after processing. These are effectively
two machine instructions. Only if no scan lock is active and PACT==TRUE,
real overhead will occur. Even this overhead is not too great a cost,
IMHO, if it solves the problem.
I haven't spent any time thinking about the most clever representation
of the 'deferred puts' in the queue but certainly this can be worked
out.
What do you think?
At the present time after initialization nothing in base except channel access
server code allocates or frees memory. Channel access server code must because
clients are connecting and disconnecting. The CA code manages memory VERY carefully.
In order to implement what you suggest the queue must be managed very carefully.
But what goes into the queue? What if the value is an array? If it is an array
record support routines are involved. What fields of a record are involved? Note
that for the bo record only the VAL field is a problem because this is the only
field that the bo record support compares with MLST.
Ben
P.S. I have the impression that nowadays asynchronous processing is
rather the rule than the exception, with the wide adoption of field
busses. Here at BESSY more than half the records with hardware device
support use CAN bus and so are asynchronous.
GTACS, the precurser of EPICS, did not have the concept of asynchronous records.
Device support had to be written so that it was synchronous. Asyn support was
invented for gpib devices. Once it was available people found many uses for it.
Sigh!!
Marty
- Replies:
- Re: Changes to records during asynch processing Benjamin Franksen
- Re: Changes to records during asynch processing Benjamin Franksen
- References:
- Does DISP work for DB OUT links? Benjamin Franksen
- Re: Does DISP work for DB OUT links? Marty Kraimer
- Re: Does DISP work for DB OUT links? Benjamin Franksen
- Re: Does DISP work for DB OUT links? Marty Kraimer
- Re: Does DISP work for DB OUT links? Related question Benjamin Franksen
- Re: Does DISP work for DB OUT links? Related question Marty Kraimer
- Changes to records during asynch processing Benjamin Franksen
- Navigate by Date:
- Prev:
Re: Changes to records during asynch processing Benjamin Franksen
- Next:
Re: [Fwd: Re: Does DISP work for DB OUT links? Related question] Marty Kraimer
- 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: Changes to records during asynch processing Benjamin Franksen
- Next:
Re: Changes to records during asynch processing Benjamin Franksen
- 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
|