Experimental Physics and
Industrial Control System

Ben Franksen <[email protected]> · Tue, 9 Nov 2010 00:46:57 +0100

On Mittwoch, 27. Oktober 2010, Tim Mooney wrote:
> One point that is probably obvious to you guys, but was obvious to me
> only in retrospect,
> is that it matters *where* in the processing chain the asynchronous
> record occurs.
>
> If the only asynchronous record in the chain is the first one, you
> can get good behavior
> from a sequence of ca_put_callbacks and be fooled into thinking that
> server-side code
> is more aware of putNotify than it actually is.  This is because the
> first record's PACT field
> will be True all the while the putNotify is active, so server-side
> code, which only honors
> record locks and PACT fields, will accidentally be honoring putNotify
> as well.
>
> To make a good ca_put_callback test, you have to write to a
> synchronous record that links
> to an asynchronous record.  In this case, when the first record has
> written to the asynchronous
> record, and that record has gone into its asynchronous wait, both the
> lockset and the
> first record's PACT field will look ready for another
> ca_put_callback, but the putNotify
> fields will not be ready, and you'll be able to see the problem you
> need to defend against.

I made such a test, using a bo record that writes to a seq with a delay 
of 2 seconds, which in turn writes to yet another bo. The test uses 
several ca_put_callback requests to the (first) bo record in a row with 
a small delay (0.2 seconds) in between. I make sure that CA client 
buffer is flushed after each call.

The results clearly show that ca_put_callback requests are queued in the 
server, even though the targeted bo record is certainly *not* 
asynchronous (DTYP=Soft Channel), although the next record in the 
processing chain --the seq record-- is (because of the delay). I 
receive the callbacks, one after the other, with the same delay in 
between as I have configured in the seq record; this is long after all 
the ca_put_callback requests have been sent. I do not get a bad status 
from the callbacks.

I am very glad I got these results, because this is how it should be! It 
means I can treat pvPut/ASYNC in the sequencer in the same way as 
pvGet/ASYNC, i.e. requests and callbacks can overlap.

(Note, however, that this result is with multiple ca_put_callbacks from 
the same client and to the same PV. I have not yet tested what happens 
if I target different fields of the same record.)

Cheers
Ben

Experimental Physics and Industrial Control System

Experimental Physics and
Industrial Control System