Experimental Physics and
Industrial Control System

"Hill, Jeff" <[email protected]> · Thu, 21 Jun 2012 16:06:11 +0000

Hi Daron,

Correct, the CA server doesn’t allow more than one put notify to be outstanding at a time for any particular channel that a CA client application creates. If it did this wouldn’t allow a 2nd db put notify request to break in before the first one that was initiated completes, but it would allow the IOC to run out of memory if the client application issued many put callback requests, one after another, against a slow record such as a motor record.

db put semantics
----------------

ordinary db put (ca put): If multiple requests are pending, intermediate requests may be discarded but the last put request is always fulfilled.

db put notify (ca put callback): All put requests are executed exactly in the order that they are issued.

Jeff

> -----Original Message-----
> From: [email protected] [mailto:[email protected]]
> On Behalf Of Andrew Johnson
> Sent: Thursday, June 21, 2012 9:43 AM
> To: [email protected]
> Cc: Daron Chabot
> Subject: Re: put callback queuing
> 
> Hi Daron,
> 
> On 2012-06-21 Daron Chabot wrote:
> > Recently at BNL, we've been investigating a report of unexpected
> > behavior found when using put-callbacks to a Motor Record (verified
> > using a simulated motor). After initiating a long-running motion with
> >
> > caput -c -w 100 test:motor1 <some large value>
> >
> > trying to stop the motor in the following way fails:
> >
> > caput -c -w 100 test:motor1.STOP 1
> 
> ...
> 
> > I can understand serializing put-callbacks on a per-channel basis, but
> > the implementation appears to serialize _per-record_.
> >
> > What am I missing? A little help please...
> 
> That's how the putNotify code works inside the IOC; there can only be one
> putNotify operation outstanding on any record at a time, basically because
> there is only one field in each record that stores the putNotify status
> information, it's too hard to try and keep track of multiple operations at
> once, and it's questionable what that would actually mean.  The putNotify
> functionality has to keep track of the putNotify state through
> asynchronous
> record processing and across PP database links, which makes it pretty
> complicated.  There is an enhanced version of the putNotify code called
> process-get which Marty wrote in 2008 that will be in the 3.15.0 release,
> but
> it doesn't change the 'one notify per record' limit that you've hit.
> 
> Thus you should *not* use put-callback for writing to the .STOP field, for
> exactly this reason, use a regular put:
> 
> caput test:motor1.STOP 1
> 
> HTH,
> 
> - Andrew
> --
> Never interrupt your enemy when he is making a mistake.
> -- Napoleon Bonaparte

Experimental Physics and Industrial Control System

Experimental Physics and
Industrial Control System