Experimental Physics and
Industrial Control System

Marty Kraimer <[email protected]> · Thu, 28 Aug 2003 07:35:14 -0500

Benjamin Franksen wrote:

Marty Kraimer wrote:
Benjamin Franksen wrote:
Marty Kraimer wrote:
Benjamin Franksen wrote:
I mean, if DISP=TRUE, does this also disable setting fields via db (out)
links?

dbPutField and dbPutNotify requests are disabled.
This it only disables Channel Access puts.
Database links are NOT disabled.
Channel Access client puts (this includes CA links) are disabled.

Is there any way to disable *all* puts to a record?

No.

Marty,
thanx for your answers. I just asked myself what happens when the record
is being processed (scan lock active). Then remembered that records with
out links are *always* in the same lockset with the target record (even
if NPP NMS), so this will prevent the record that is being processed
from outside field changes.
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.
The following assumes a passive record.
If a value is written to a record between the two phases of record processing
the following is done.
The value is written to the record. If the field has pp(TRUE), i.e. process
passive, the record will be processed again when the record completes
asynchronous processing.
Thus can lead to strange side effects.
Kay Kasemir and Jeff Hill just told me of one.
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.
See the 3.14 Application Developer's Guide
    Chaper: Database Locking, Scanning, and Processing
    Section Guidelines for Asynchronous Records
    Section: Cached Puts
    Section putNotify
I see no easy solution and perhaps no solution without significent runtime overhead.

Marty Kraimer

Experimental Physics and Industrial Control System

Experimental Physics and
Industrial Control System