Experimental Physics and
Industrial Control System

"Jeff Hill" <[email protected]> · Mon, 19 Nov 2001 15:17:06 -0700

> Won't the overall behavior be approximately the same? I mean, eventually
> there will be stuff for CA to do and won't it get done in a ca_pend_io
> call? 

The ca_pend_io() function was designed to block until all of the
IO requests pending from the set I enumerated in my last message have
completed, or until the timeout expires - whichever is first.

If no IO requests from this set are pending then ca_pend_io() will flush 
the output queue and return - that's it - nothing else is done.

> It seems to me that the 2nd example will get it done perhaps
> .1 second before the 1st and not 4 seconds before (like I observe when
> processing many, many events).

In the first example the forever loop performs no CA background activities
because ca_pend_io() is called when there are no callback challenged 
disconnected channels, and no callback challenged get requests pending.

In the second example you are polling ca_pend_event() ( or ca_poll ) as is 
recommended for complex gui's such as edm and therefore CA background 
activities such as connecting channels and responding to subscription
update messages are taken care of.

I recommend calling ca_poll() from within your Motif periodic background 
activity callback, or alternatively, with R3.14 and a thread safe code,
you could enable preemptive callback and not worry about polling CA.

Jeff

> -----Original Message-----
> From: john sinclair [mailto:[email protected]]
> Sent: Monday, November 19, 2001 1:42 PM
> To: Jeff Hill
> Cc: tech talk
> Subject: RE: channel access
> 
> 
> So I still don't understand the difference between these two code block
> examples:
> 
>   1)
> 
>     do forever {
> 
>       <whatever>
> 
>       ca_pend_io( 5.0 )
> 
>       delay .1 seconds
> 
>     }
> 
> 
>   2)
> 
>     do forever {
> 
>       <whatever>
> 
>       ca_pend_io( 5.0 ) 
> 
>       ca_pend_event( 0.1 )
> 
>     }
> 
> 
> Won't the overall behavior be approximately the same? I mean, eventually
> there will be stuff for CA to do and won't it get done in a ca_pend_io
> call? It seems to me that the 2nd example will get it done perhaps
> .1 second before the 1st and not 4 seconds before (like I observe when
> processing many, many events).
> 
> Sorry for being so obtuse.
> 
> John Sinclair
> 
> 
> 
> On Mon, 19 Nov 2001, Jeff Hill wrote:
> 
> > 
> > > Is this behavior reasonable? Does pend event do something fundamentally
> > > different from pend io?
> > 
> > Yes. If you have not made any of the following IO requests since the last
> > call to ca_pend_io() (or the start of the program whichever is first), then
> > ca_pend_io() will have no effect other than to flush the output queue,
> > and ca_pend_io() will return immediately without blocking for the duration
> > of the specified time out.
> > 
> > 1) created a CA channel (without specifying a connection call back handler)
> > 2) made a CA get request (without specifying an IO completion call back handler)
> > 
> > In contrast ca_pend_event() will always process CA background activity
> > for the full duration of the specified timeout and until all queued
> > labor has been processed by CA. 
> > 
> > You should call ca_poll() or ca_pend_event(1e-12) in the background at least 
> > a 10 Hz rate. Alternatively, in EPICS R3.14 if your application is thread safe, 
> > you can enable preemptive call backs and not bother with polling ca_pend_event().
> > 
> > Jeff
> > 
> > > In the course of testing edm, I have noticed the following behavior for
> > > some configurations (unfortunately, I don't mean anything precise when I
> > > say "some configurations"):
> > > 
> > >   I run a fresh copy of edm, bring up a display containing ~9000
> > >   references to the same pv  and execute it. This adds ~9000 events to the
> > >   ioc (or portable CAS). Performance is good.
> > > 
> > >   I now deactivate the display which clears all the events.
> > > 
> > >   From this point on, when this or any other display is executed, the
> > >   performance is such that it takes twice as long to complete the
> > >   process of adding all the events.
> > > 
> > > 
> > > 
> > > At this point the code looked something like the following:
> > > 
> > > ====================================
> > > 
> > >   for all pvs {
> > > 
> > >     add events
> > > 
> > >   }
> > > 
> > >   ca_pend_io( time )
> > > 
> > > ====================================
> > > 
> > > 
> > > 
> > > So, I changed this to
> > > 
> > > ====================================
> > > 
> > >   count=0
> > >   for all pvs {
> > > 
> > >     add events
> > >     if ( ++count > someNumber ) {
> > >       ca_pend_io( time )
> > >       count=0
> > >     }
> > > 
> > >   }
> > > 
> > >   ca_pend_io( time ) 
> > > 
> > > ====================================
> > > 
> > > 
> > > 
> > > This did not help at all. Then I change to code to
> > > 
> > > ====================================
> > > 
> > >   count=0
> > >   for all pvs {
> > > 
> > >     add events           
> > >     if ( ++count > someNumber ) {
> > >       ca_pend_io( time )
> > >       ca_pend_event( small-time )
> > >       count=0
> > >     }
> > >  
> > >   }
> > > 
> > >   ca_pend_io( time )
> > >   ca_pend_event( small-time )
> > > 
> > > ====================================
> > > 
> > > 
> > > 
> > > This made an amazing difference and now the performance is good all the
> > > time.
> > > 
> > > Is this behavior reasonable? Does pend event do something fundamentally
> > > different from pend io?
> > > 
> > > 
> > > John Sinclair
> > > [email protected]
> > > Oak Ridge National Lab
> > > 865-576-6362   865-574-1268 (fax)
> > > 
> > 
> 
> John Sinclair
> [email protected]
> Oak Ridge National Lab
> 865-576-6362   865-574-1268 (fax)
> 

Experimental Physics and Industrial Control System

Experimental Physics and
Industrial Control System