Experimental Physics and
| |||||||||||||||
|
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
| ||||||||||||||
ANJ, 10 Aug 2010 |
·
Home
·
News
·
About
·
Base
·
Modules
·
Extensions
·
Distributions
·
Download
·
· Search · EPICS V4 · IRMIS · Talk · Bugs · Documents · Links · Licensing · |