Experimental Physics and
Industrial Control System

Ben Franksen <[email protected]> · Wed, 27 Oct 2010 01:03:23 +0200

Hi Andrew

thanks for the clarification. This means one has to be a careful when 
using pvPut(var, SYNC) or pvPut(var, ASYNC) in SNL code, i.e. check the 
return/status code, at least if there is an asoynchronous record in the 
processing chain. I wonder, maybe the sequencer should rather queue 
such requests? This will not work of course if two tasks hammer away at 
the same variable but I think we can safely book this under 'bad 
program, bad results'. However, if there is just a small but non-zero 
chance that such a collision happens, occasionally having to wait a bit 
longer would be a nice alternative to failure.

BTW, I have often wondered why there is no middle ground between plain 
ca_put (fire & forget) and ca_put_callback (with the mighty putNotify 
machinery on the server side). In many cases I'd be happy to know that 
the value was written to the PV, no need to wait until all the 
resulting processing (especially if asynchronous) is done.

On Mittwoch, 27. Oktober 2010, Andrew Johnson wrote:
> Hi Ben,
>
> I disagree with Jeff's response to this part of your question:
>
> On Tuesday 26 October 2010 15:17:36 Ben Franksen wrote:
> > combinations which will fail ("sorry, pv is active")? I remember
> > reading some time ago that only one *db*_put_callback can be active
> > at a time on a record (on the IOC), so will interleaving two
> > ca_put_callbacks also fail?
>
> He said there are no combinations that will fail, but he's wrong
> about the ca_put_callback() that you remember reading about, the
> operation can (and does) fail in some circumstances.
>
> The IOC database can only have one putNotify operation active on a
> particular record at once.  The server side of a ca_put_callback()
> operation uses the IOC's putNotify mechanism to process the record
> and discover when the processing chain has completed, which is when
> it notifies the client.  If your first ca_put_callback() has not
> completed when the second one is processed, it will be rejected. 
> This requires that at least one of the records in the processing
> chain be asynchronous though.
>
> If the processing chain is all synchronous then the record processing
> all takes place in the context of one of the RSRV (CA server) tasks. 
> In this case the putNotify completion will be called from the
> recGblFwdLink() processing of the last record in the chain, but still
> in the context of the RSRV thread, so the CA server can't start
> processing your second ca_put_callback() request until the first one
> has finished and there's no conflict between your two
> ca_put_callback() operations.
>
> However that's not going to be true if there's any asynchronous
> processing involved.  In that case the putNotify can still be active
> when the process() operation requested by RSRV thread returns, so the
> server can try processing the second ca_put_callback() operation but
> it may be rejected.
>
> Of course if the CA server you're talking to is not an IOC database
> then the behaviour you get depends on capabilities of the underlying
> server tool, which might perversely object to some other interleaving
> that the IOC database has no problems with.

Experimental Physics and Industrial Control System

Experimental Physics and
Industrial Control System