Re: put callback queuing

[Tim Mooney <mooney@aps.anl.gov>]

Daron,

It intends to do that, because even if a record were capable of keeping track of more than one completeable command, it has no way to tell EPICS which command just completed.  All it has is its forward link, which communicates an unqualified "done".  So there wouldn't have been a reason to implement a mechanism that could track more than one putNotify on a record at a time.

Tim

----- Original Message -----
From: "Daron Chabot" <daron.chabot@gmail.com>
To: "EPICS" <tech-talk@aps.anl.gov>
Sent: Thursday, June 21, 2012 9:50:40 AM
Subject: put callback queuing

Hi,

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

After observing that the 2nd put-with-callback to stop the motion is
not seen by the Motor Record, a look through
$EPICS_BASE/src/rsrv/camessage.c reveals that concurrent put notifies
are queued in the IOC server:

/******************************/
if ( pciu->pPutNotify ) {

        /*
         * serialize concurrent put notifies
         */
/******************************/

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...


-- dc

-- 
Tim Mooney (mooney@aps.anl.gov) (630)252-5417
Software Services Group (www.aps.anl.gov)
Advanced Photon Source, Argonne National Lab