Experimental Physics and
Industrial Control System

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.

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: Warning: message 19rjRN-0005cS-PQ delayed 48 hours Mail Delivery System

Next: [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: 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