RE: Process ordering in CA and asyn

["Rees, NP (Nick)" <nick.rees@diamond.ac.uk>]

Hi,

Jeff (or Andrew) can you clarify this, or tell us which bit the TFM we
should read. I thought that the initial record process() associated with
a ca_put happened in the context of the CAS-client task associated with
the client. Thus, if all puts are from the same client to a single IOC,
then the initial process() calls will happen in the context of a single
task and these process() calls will be executed in order of client
dispatch.

Since, in this case, every one of these initial process() calls will put
the event associated with each put on the same asyn queue (since there
is only one asyn queue per asyn port), then the processing in the asyn
driver will also happen in the same order.

So, whilst what Jeff says can be true from the CA perspective, I hope
that the overall design of the complete system means that things are
more predictable than this.

Even if I am right in all this, one thing I am not clear on is the
context of a queued ca_put_callback. Does this happen in the context of
the CAS-client task (i.e. this checks for completion of any records it
is pending on in its event loop) or does it happen in the context of
some other task (scanOnce or the task that calls recGblFwdLink are ones
that spring to mind).

Cheers,

Nick Rees
Principal Software Engineer           Phone: +44 (0)1235-778430
Diamond Light Source                  Fax:   +44 (0)1235-446713 

> -----Original Message-----
> From: tech-talk-bounces@aps.anl.gov 
> [mailto:tech-talk-bounces@aps.anl.gov] On Behalf Of Jeff Hill
> Sent: 21 May 2009 01:21
> To: Pearson, MR (Matthew); tech-talk@aps.anl.gov
> Subject: RE: Process ordering in CA and asyn
> 
> 
> > I know channel access has a sequence ID that the channel 
> > access server uses to re-order CA events on the IOC, and 
> > process them in sequence order number (is that right?).
> 
> The CA UDP frames have a sequence number, but this is 
> applicable only to
> search requests and beacon messages.
> 
> Concerning ca put requests:
> O All CA put requests are _initiated_ with the database in the IOC in
> exactly the same order as they are received by the CA client library.
> However, the behavior is more complex once you look at what 
> happens after
> the request is initiated in the database. 
> O If it's a CA put request then the requests are initiated 
> asynchronously.
> That is they are initiated independently of when they complete. If the
> database record has asynchronous processing in progress when 
> the put occurs
> then the record is processed again with the most recent value 
> (potentially
> replaced by a put occurring while the record is finishing asynchronous
> processing in progress).
> O If it's a CA put callback request then each and every 
> request is executed
> by the database, but the order of execution (in the database) 
> can change
> subtly depending on whether the device support of the record 
> (or records it
> forward links to) has asynchronous completion. In summary, in 
> the IOC a
> subsequent CA put request for record A can be initiated with 
> the database
> while we are waiting for a previous put request for a record 
> B that has
> asynchronous completion to complete. If there is a subsequent 
> put callback
> request for a record B, that already has a put callback 
> request in progress,
> then the CA server will block processing of further requests from that
> client until any put callback request in progress with record 
> B completes.
> O The client side application will block if the put request 
> generation rate
> exceeds the put request consumption rate of the database.
> 
> > 
> > On my client side, I do a series of ca_put()s, and 
> > call ca_pend_event() after each one. But I understand 
> > that the CA client is not guaranteed to service the 
> > event when calling ca_pend_event(). 
> 
> The ca_pend_event() will cause a CA flush to occur. That 
> causes requests
> that are queued in the client library to be flushed to the 
> TCP pipe. In
> non-preemptive callback mode the ca_pend_event() call will also cause
> pending response callbacks to be executed.
> 
> > So is the CA sequence
> > number assigned to an event at the ca_put() stage, or the at the
> > ca_pend_event() stage?
> 
> The sequence numbers apply to UDP based search and beacon 
> request frames
> only. With the TCP based put requests put request initiation  
> ordering is
> preserved by a combination of the TCP implementation and also the
> implementation of the CA client and server libraries.
> 
> HTH,
> 
> Jeff 
> 
> 
This e-mail and any attachments may contain confidential, copyright and or privileged material, and are for the use of the intended addressee only. If you are not the intended addressee or an authorised recipient of the addressee please notify us of receipt by returning the e-mail and do not use, copy, retain, distribute or disclose the information in or attached to the e-mail.
Any opinions expressed within this e-mail are those of the individual and not necessarily of Diamond Light Source Ltd. 
Diamond Light Source Ltd. cannot guarantee that this e-mail or any attachments are free from viruses and we cannot accept liability for any damage which you may sustain as a result of software viruses which may be transmitted in or with the message.
Diamond Light Source Limited (company no. 4375679). Registered in England and Wales with its registered office at Diamond House, Harwell Science and Innovation Campus, Didcot, Oxfordshire, OX11 0DE, United Kingdom