Experimental Physics and Industrial Control System
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.
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
- Replies:
- Re: Changes to records during asynch processing Tim Mooney
- 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
- Navigate by Date:
- Prev:
Home signal does not affect the .ATHM field of the motor record Rok Sabjan
- Next:
Re: [Fwd: Re: Does DISP work for DB OUT links? Related question] Brian Bevins
- 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 Benjamin Franksen
- Next:
Re: Changes to records during asynch processing Tim Mooney
- 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