Argonne National Laboratory

Experimental Physics and
Industrial Control System

1994  1995  1996  1997  1998  1999  2000  2001  2002  2003  2004  2005  2006  2007  2008  2009  2010  2011  <20122013  2014  2015  2016  2017  2018  2019  Index 1994  1995  1996  1997  1998  1999  2000  2001  2002  2003  2004  2005  2006  2007  2008  2009  2010  2011  <20122013  2014  2015  2016  2017  2018  2019 
<== Date ==> <== Thread ==>

Subject: RE: put callback queuing
From: "Hill, Jeff" <johill@lanl.gov>
To: "tech-talk@aps.anl.gov" <tech-talk@aps.anl.gov>
Cc: Daron Chabot <daron.chabot@gmail.com>
Date: 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: tech-talk-bounces@aps.anl.gov [mailto:tech-talk-bounces@aps.anl.gov]
> On Behalf Of Andrew Johnson
> Sent: Thursday, June 21, 2012 9:43 AM
> To: tech-talk@aps.anl.gov
> 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


References:
put callback queuing Daron Chabot
Re: put callback queuing Andrew Johnson

Navigate by Date:
Prev: Re: put callback queuing Tim Mooney
Next: Re: put callback queuing Tim Mooney
Index: 1994  1995  1996  1997  1998  1999  2000  2001  2002  2003  2004  2005  2006  2007  2008  2009  2010  2011  <20122013  2014  2015  2016  2017  2018  2019 
Navigate by Thread:
Prev: Re: put callback queuing Andrew Johnson
Next: Re: put callback queuing Tim Mooney
Index: 1994  1995  1996  1997  1998  1999  2000  2001  2002  2003  2004  2005  2006  2007  2008  2009  2010  2011  <20122013  2014  2015  2016  2017  2018  2019 
ANJ, 18 Nov 2013 Valid HTML 4.01! · Home · News · About · Base · Modules · Extensions · Distributions · Download ·
· Search · EPICS V4 · IRMIS · Talk · Bugs · Documents · Links · Licensing ·