Experimental Physics and
Industrial Control System
| 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 | 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 |
| <== Date ==> | <== Thread ==> |
|---|
| Subject: | Re: Changes to records during asynch processing |
| From: | Tim Mooney <[email protected]> |
| To: | Marty Kraimer <[email protected]> |
| Cc: | [email protected] |
| Date: | Tue, 02 Sep 2003 12:42:38 -0500 |
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
·
Home
·
News
·
About
·
Base
·
Modules
·
Extensions
·
Distributions
·
Download
·
· Search · EPICS V4 · IRMIS · Talk · Bugs · Documents · Links · Licensing ·