EPICS Controls 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  <20102011  2012  2013  2014  2015  2016  2017  2018  2019  2020  2021  2022  2023  2024  Index 1994  1995  1996  1997  1998  1999  2000  2001  2002  2003  2004  2005  2006  2007  2008  2009  <20102011  2012  2013  2014  2015  2016  2017  2018  2019  2020  2021  2022  2023  2024 
<== Date ==> <== Thread ==>

Subject: Re: ca_put_callback once again
From: Ben Franksen <[email protected]>
To: [email protected]
Date: Tue, 23 Nov 2010 04:59:04 +0100
Hi Andrew

We have two separate issues here.

(1) The bo record. I was aware of the fact that the bo record does not 
remain  active during its HIGH time. Maybe I should have explained the 
idea behind the test db file a bit more, but I added the test setup as 
an afterthought and the mail was already long enough. I am using the bo 
record's HIGH field only so that I can see a change in the value with a 
camonitor in another window. The actual asynchronous processing is done 
by the seq record which has a longer delay for exactly this reason. I 
could as well have used a longout for the two "front-end" records and 
the result would have surprised me as much.

I am not proposing to change the bo behaviour.

(2) The putNotify behaviour. I admit that I did not read the manual 
carefully enough. You cite the ADG:

>     6. In general a set of records may be processed as a result of a
> single dbPutNotify. If a record in the set is found to be active,
> either because PACT is true or because a putNotify already owns the
> record, then that record is not made part of the set of records that
> must complete before the putNotify request completes.

This should have led me to expect the behaviour I see.

> Your second caput is completing immediately because its bo record
> tries to process the OUT link but finds the seq.PACT=TRUE, so it
> gives up and tells putNotify that everything it started has finished.

Agreed, but this is exactly the problem I complained about.

It tells me that an operation successfully completed, when in fact it 
did *not* succeed. The bo was supposed to start more than its own 
processing, namely processing of the seq record, and this id not 
happen. It should be possible to record such a failure and return it to 
the requester. Even better, the CA server could detect the failure and 
wait until the record in question is no longer busy. It already does so 
under certain circumstances, namely if I target the same front-end 
record from the same client: in this case the second call waits for the 
first fo finish, i.e. the CA server queues the second request. 
(Unfortunately I cannot as easily demonstrate this because caput does 
not allow to group several asynchronous put operations in one command.)

If I target a different record (even from the same client), this queuing 
does not happen. This is inconsistent. I think that the queueing should 
ideally always happen for ca_put_callback as long as any record in teh 
chain is busy. Failing that, or if the wait times out, at least an 
error should be sent back.

Considering the effort that went into the implementation of the 
putNotify feature it seems a shame that it cannot be used for what it 
was designed, at least not reliably.

Since I don't expect this will be fixed any time soon, I will warn users 
of the sequencer that using pvPut(var,SYNC) is inherently unreliable. 
Instead completion should be detected by other means, such as reading 
back a status bit from the hardware.

Cheers
Ben

Replies:
RE: ca_put_callback once again Jeff Hill
Re: ca_put_callback once again Tim Mooney
Re: ca_put_callback once again Ben Franksen
References:
ca_put_callback once again Ben Franksen
Re: ca_put_callback once again Andrew Johnson

Navigate by Date:
Prev: Re: ca_put_callback once again Andrew Johnson
Next: MAXv issue Dirk Zimoch
Index: 1994  1995  1996  1997  1998  1999  2000  2001  2002  2003  2004  2005  2006  2007  2008  2009  <20102011  2012  2013  2014  2015  2016  2017  2018  2019  2020  2021  2022  2023  2024 
Navigate by Thread:
Prev: Re: ca_put_callback once again Andrew Johnson
Next: RE: ca_put_callback once again Jeff Hill
Index: 1994  1995  1996  1997  1998  1999  2000  2001  2002  2003  2004  2005  2006  2007  2008  2009  <20102011  2012  2013  2014  2015  2016  2017  2018  2019  2020  2021  2022  2023  2024 
ANJ, 23 Nov 2010 Valid HTML 4.01! · Home · News · About · Base · Modules · Extensions · Distributions · Download ·
· Search · EPICS V4 · IRMIS · Talk · Bugs · Documents · Links · Licensing ·