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
- 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
<2012>
2013
2014
2015
2016
2017
2018
2019
2020
2021
2022
2023
2024
- 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
<2012>
2013
2014
2015
2016
2017
2018
2019
2020
2021
2022
2023
2024
|