Marty Kraimer wrote:
Some further thoughts about what should happen if a put request is made
between the start and completion of asynchronous processing.
One suggestion was that all such puts should be queued. I do not like
this because it can a very heavyweight operation. I maintain that the
existing semantics are mostly correct but a bug is present.
An example of the bug is: A boRecord has the value 0, The value 1 is
written and before asynchronous completion occurs the value 0 is
written. At present No CA monitors will be issued. If the record is
synchronous two monitors will be issued, i.e. one with tha value 1 and a
second with the value 0.
I claim that the only fields which present this problem are the VAL (or
closely related fields) of output records. In particular for the records
in base only the VAL fields of the ao, bo, longout, and mbbo records are
a problem.
Brief Explaination:
dbAccess:dbPut, not record support, calls db_post_event for most field
changes. A VAL field with pp(TRUE) is the only exception. In this case
record support is expected to call db_post_event.
Since input records normally provide a new value to VAL, the put value
is overriden when the record is processed, because VAL will receive a
new value. A soft record with a NULL INP is an exception but then the
record is synchronous.
Thus only the VAL field of output records are a problem.
I think the absence of a monitor on the VAL field is not the most serious
problem that can occur when dbPutField() or dbPutLink() writes to a record
while the record is processing. Any algorithm the record may be performing,
involving any writable field, is vulnerable to a dbput() during the I/O-wait
part of asynchronous processing. You can't depend on any field value unless
you've cached it, or declared the field "special" in the .dbd file. If the
dbPutXxxx() does not also cause processing, the record gets no hint at all
that a field was changed during processing; if the dbPutXxxx() *does* cause
processing, that processing (currently) is separated in time and circumstance
from the value change, and it generally cannot be expected to have the same
effect as if the two had occurred together.
And it doesn't end there, of course. The effects of outside interference
in asynchronous record processing can carry over to sabotage algorithms a
database may be trying to execute, if records in the database are asynchronous.
Generally, one would like to be able to run a database algorithm with either
synchronous or asynchronous records, because it normally is not the database
designer, but the end user, who chooses the I/O devices. This doesn't always
work because records can behave much differently with asynchronous I/O devices
than they would with synchronous devices. I have databases thoroughly littered
with records whose only purpose is to try to defend against value changes from
CA clients during database-initiated record processing.
No one would suggest that synchronous records should have to defend their fields
against outside interference during processing. I think the objective of
asynchronous processing rules should be to approximate, as closely as is
practical, the relatively safe environment enjoyed by synchronous records.
I think EPICS should never write to any record while PACT==1. (I'd like
to say that scanLock should persist through the I/O-wait period of asynchronous
processing, so that dbPutField could not modify any field in a lockset while
asynchronous processing was going on in that lockset, but I don't know enough
about the consequences of this.) Anyway, maybe .RPRO should be used not only
to signal that a record should be reprocessed, but also to cache the field name
and value that should be written. This would handle the problem of a
dbPutField to a record during asynchronous processing that was started by
a dbPutLink. It wouldn't necessarily handle the problem of a dbPutLink to
a record during asynchronous processing that was started by a dbPutField,
because the record that caused the dbPutLink might have gone on to initiate
other processing sensitive to the field whose write has been postponed.
Here is how the bug can be fixed.
Let's consider the boRecord.
Review: Problem is
1) record has value 0 and a 1 is written. The record starts the first
phase of record processing. The RVAL obtained from VAL=1 is sent to the
hardware.
2) While PACT is true the value 0 is written to the record.
3) Asyn completion occurs.
4) Record is processed again. The RVAL obtained from VAL=0 is sent to
the hardware.
5) Asyn completes.
If a CA is monitoring the VAL field we would like two monitors
1) VAL=1 is returned. Status, Severity, Time stamp are all the result of
VAL=1
2) VAL=0 is returned. Status, Severity, Time stamp are all the result of
VAL=0.
At present NO monitors are send because each time record completion
occurs VAL is 0. When record support compares VAL with MLST they are
always equal and db_post_event is not called.
Here is a way to fix the bug.
The VAL field is declared special(SPC_MOD).
This means the record support will be notified both before and after VAL
is written. It could then do the following if it finds PACT true
Keep the value being written somewhere but leave VAL with the original
value.
When asyn completion occurs do as normal until the end. After calling
db_post_event it sets VAL equal the the value it saved. Thus when the
second process starts the field has the value corresponding to the
second put.
Marty Kraimer
I think it might be easier and better to make .RPRO a structure in which
the whole of a dbPutLink or dbPutField could be cached, and applied after
the record has called recGblFwdLink().
--
Tim Mooney ([email protected]) (630)252-5417
Beamline Controls & Data Acquisition Group
Advanced Photon Source, Argonne National Lab
- Replies:
- Re: Changes to records during asynch processing Peregrine M. McGehee
- 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
- 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
- Navigate by Date:
- Prev:
RE: [Fwd: Re: Does DISP work for DB OUT links? Related question] Jeff Hill
- Next:
Re: Changes to records during asynch processing Peregrine M. McGehee
- 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 Marty Kraimer
- Next:
Re: Changes to records during asynch processing Peregrine M. McGehee
- 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
|