Experimental Physics and
Industrial Control System

"Jeff Hill" <[email protected]> · Tue, 26 Oct 2010 17:35:02 -0600

> > > What if I interleave a synchronous ca_get
> > > (i.e. I wait for completion using ca_pend or somesuch) with a
> > > ca_get or ca_get_callback issued by another thread?
> >
> > Only a thread which has initialized the library in
> > non-preemptive callback mode can call ca_pend_io to
> > rendezvous with completion of a batch of no-callback
> > gets which have been requested;
> 
> I didn't know that. What happens if I do it anyway, i.e. call a regular
> ca_get in preemptive callback mode twice in a row and then (try to)
> wait for the result using ca_pend_io? (Same thread).

After a close look at the source code I will have to revise 
my earlier statement (which was working from memory) as follows.

It works just fine to use no-callback get in non-preemptive callback
mode, but ca_pend_io must always be used by only one thread at a
time for a particular batch of no-callback gets that might be 
outstanding. Calling, ca_pend_io from two threads at the same time
will result in undefined behavior (waiting too long, disrupting
the mechanism that counts the number of outstanding gets, disrupting 
the mechanism that keeps batches of gets independent, etc). There,
isn't a risk of a crash but instead confusion if two threads were 
to call ca_pend_io simultaneously. 

>
> Wait, do I understand this right? How can I get a callback if I do plain
> ca_get? 

The plain (no-callback) get only calls back behind-the-scenes.

> Or did you mean: in preemptive callback mode plain ca_get (no
> callback) is always blocking?

Negative, no-callback ca get is always blocking only to enque the 
get request, and hopefully the above correction should address the 
rest of your question.

Updated the bug entry for the doc.

PS: CA synchronous group api provides an alternative blocking primitive for
both preemptive and non-preemptive mode ca clients. The synchronous group
api allows two preemptive mode threads to block independently as 
long as they use independent synchronous group identifiers, but similar warnings (as above) about blocking for the same group in two threads simultaneously probably apply also to ca sync group blocking calls.

PPS: In a future release it would probably be appropriate to move the 
state which is accessed by no-callback get and ca_pend_io, and the blocking
components of ca synchronous groups, into a thread private variable. This
would eliminate any possibility of two threads manipulating these state
variables at the same time, and produce a more predictable user experience. 
I created a new LP bug entry 667062.

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:[email protected]]
> On Behalf Of Ben Franksen
> Sent: Tuesday, October 26, 2010 4:24 PM
> To: [email protected]
> Subject: Re: Some Channel Access Questions
> 
> Hey Jeff
> 
> many thanks for the detailed (and prompt) answers. I am glad that there
> are no artificial restrictions to be observed from the client side.
> Interesting also to know what happens if you overload the server or the
> client library although that is not the scenario I had in mind. I was
> just concerned about 'collisions' when two or more threads occasionally
> access the same channel at (about) the same time.
> 
> Some things are still a bit unclear to me:
> 
> > > What if I interleave a synchronous ca_get
> > > (i.e. I wait for completion using ca_pend or somesuch) with a
> > > ca_get or ca_get_callback issued by another thread?
> >
> > Only a thread which has initialized the library in
> > non-preemptive callback mode can call ca_pend_io to
> > rendezvous with completion of a batch of no-callback
> > gets which have been requested;
> 
> I didn't know that. What happens if I do it anyway, i.e. call a regular
> ca_get in preemptive callback mode twice in a row and then (try to)
> wait for the result using ca_pend_io? (Same thread).
> 
> > furthermore, it's not
> > allowed to attach additional threads to a non-preemptive
> > callback mode ca context.
> 
> Yes, I knew that. So let's assume preemptive callback mode.
> 
> > So while one can mix ordinary get and callback get in
> > a non-preemptive mode ca context, a preemptive mode ca
> > context is a no-callback get free zone.
> 
> Wait, do I understand this right? How can I get a callback if I do plain
> ca_get? Or did you mean: in preemptive callback mode plain ca_get (no
> callback) is always blocking?
> 
> Cheers
> ben

Experimental Physics and Industrial Control System

Experimental Physics and
Industrial Control System