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: Changes to records during asynch processing
From: Benjamin Franksen <[email protected]>
To: [email protected]
Date: Fri, 29 Aug 2003 11:21:27 +0200
Marty Kraimer wrote:
> 
> Benjamin Franksen wrote:
> >
> > Next question: If the record is being processed asynchronously, i.e.
> > PACT=TRUE but scan lock is not active (record is waiting for the
> > prcosess callback). Then the fields are not protected from changes via
> > other records' output links, correct? I.e. one cannot rely on such a
> > record's fields having the same values as when the callback was set up
> > during the first call to process?
> 
> You are correct. This is a really nasty side effect of asynchronous processing.
> 
> [...]
>
> Assume a bo record has the value 0.
> 
> Two puts are sent to the record. The first is 1 and the second is 0.
> 
> If the first asynchronous completion occurs before the second put everything
> works just like for synchronous records. Two channel access monitors will be
> issued. The first returns 1. The second returns 0.
> 
> If the second put occurs before the asynchronous completion from the first, NO
> ca monitors are issued. The explaination is as follows:
> 
> The put of 1 occurs:
>      1 is written to the VAL field
>      The record starts synchronous processsing
> The put of 0 occurs
>      0 is written to the record
>      A flag is set requesting that the record be reprocessed
> The asynchronous completion because of the first put occurs.
>      Record support compares MLST and VAL.
>      Since they are the same because of the second put, no monitor occurs.
> The record is processed again
>      The record starts asynchronous processing
> The asynchrononous completion occurs.
>      MLST and VAL are both still 0. Thus no monitors.
> 
> Thus asynchronous records can lead to strange behavior.

Au weia (as we would say here in Germany). This is even worse than I
thought.

> I see no easy solution and perhaps no solution without significent runtime overhead.

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?

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.

Replies:
Re: Changes to records during asynch processing Marty Kraimer
Re: Changes to records during asynch processing Benjamin Franksen
Re: Changes to records during asynch processing Marty Kraimer
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

Navigate by Date:
Prev: about NFS zhaozhuo
Next: Warning: message 19rjRN-0005cS-PQ delayed 48 hours Mail Delivery System
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: Does DISP work for DB OUT links? Related question Marty Kraimer
Next: Re: Changes to records during asynch processing 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 ·