Experimental Physics and
Industrial Control System

"Jeff Hill" <[email protected]> · Tue, 23 Nov 2010 09:16:04 -0700

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

If it is desirable for the ca server to wait for some state to change in the database before proceeding then there also needs to be a mechanism for the server to be asynchronously informed when this state change occurs. Presumably in this case that would occur via the callback from dbPutNotify.

Jeff
______________________________________________________
Jeffrey O. Hill           Email        [email protected]
LANL MS H820              Voice        505 665 1831
Los Alamos NM 87545 USA   FAX          505 665 5107

Message content: TSPA

With sufficient thrust, pigs fly just fine. However, this is
not necessarily a good idea. It is hard to be sure where they
are going to land, and it could be dangerous sitting under them
as they fly overhead. -- RFC 1925

> -----Original Message-----
> From: [email protected] [mailto:tech-talk-
> [email protected]] On Behalf Of Ben Franksen
> Sent: Monday, November 22, 2010 8:59 PM
> To: [email protected]
> Subject: Re: ca_put_callback once again
> 
> 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

Experimental Physics and Industrial Control System

Experimental Physics and
Industrial Control System