EPICS Controls Argonne National Laboratory

Experimental Physics and
Industrial Control System

1994  1995  1996  1997  1998  1999  2000  2001  2002  <20032004  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  1998  1999  2000  2001  2002  <20032004  2005  2006  2007  2008  2009  2010  2011  2012  2013  2014  2015  2016  2017  2018  2019  2020  2021  2022  2023  2024 
<== Date ==> <== Thread ==>

Subject: RE: [Fwd: Re: Does DISP work for DB OUT links? Related question]
From: "Jeff Hill" <[email protected]>
To: "'Brian Bevins'" <[email protected]>
Cc: "EPICS-tech-talk" <[email protected]>
Date: Tue, 2 Sep 2003 11:17:57 -0600
> Marty Kraimer wrote:
> > An additional comments on Jeff's second suggestion:
> >
> > Fix 2:
> > There is a new field called AVAL (for asynchronous value) which is
> > initialized at the start of processing to what
> > is in the VAL field. When processing completes the AVAL field is used
> to
> > determine if monitors will be sent instead
> > of VAL.
> >
> > This does seem like it should be easy to implement.
> >
> > General Rule: Record support that allows asynchronous processing must
> do
> > this for any field for which it checks for value change before issuing
> > monitors.
> >
> > Marty Kraimer
> 
> Does this really solve the original problem? When asynchronous
> processing starts for the second put won't it overwrite what the first
> put cpoied into AVAL?
> 

Yes, that's correct, the initial phase of record processing will overwrite AVAL, but by then it doesn't matter
because AVAL will have already served its purpose which was saving the value of VAL that initiated asynchronous
processing until it completes in case dbCommon overwrites the VAL field before the device completes asynchronous
record processing.

Marty's suggestion of caching the value written to VAL during asynchronous record processing until it completes
certainly sounds like a potential improvement on my original suggestion because it fits better within the complex
record processing infrastructure. 

I should add that EPICS application developers should not be discouraged by the complexity of this particular
discussion. The topic has been the implementation details for the record processing source code which is executed
by multiple threads. The details can get to be fairly involved. The intent is for the implementation details to
become more complex so that runtime behavior will be more uniform. Therefore, if you are not writing record support
or maintaining dbCommon then the proposed fix should be perceived as a simplification to the EPICS system.

Jeff



References:
Re: [Fwd: Re: Does DISP work for DB OUT links? Related question] Brian Bevins

Navigate by Date:
Prev: building medm on RH9/RH Motif Arne P. Freyberger
Next: Re: Changes to records during asynch processing Tim Mooney
Index: 1994  1995  1996  1997  1998  1999  2000  2001  2002  <20032004  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: [Fwd: Re: Does DISP work for DB OUT links? Related question] Brian Bevins
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  <20032004  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 ·