CA Documentation Gaps

[Jeff Hill]

> if I fire two ca_get_callback on the
> same channel in a row, do I get two callbacks, too?

yes

> Are there any combinations which will fail
> ("sorry, pv is active")?

No, and in fact if you produce {get, get callback,
or put callback} requests at a rate higher than
than they can be consumed by the channel's record then
the producer (the client app) will eventually block
until the record consumes enough buffer space to allow
for additional requests to be enqueued.

> so will interleaving two ca_put_callbacks also fail?

Negative, but the blocking scenario is however more likely
with put callback because, if a put callback is already in
progress for the same channel, the server's per-client
thread will wait until record processing (both synchronous
or asynchronous), and all side effect record processing
(both synchronous or asynchronous) finish before initiating
another put callback request.

In contrast get and get callback only need to obtain the db
scan lock before they can execute. In current versions of
EPICS a get/get callback do _not_ initiate record processing.

> 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; furthermore, it's not
allowed to attach additional threads to a non-preemptive
callback mode ca context.

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.

> Cheers (head smoking)

:-)

This probably raises some concerns about documentation
gaps so I created a bug entry at lp.

[Jeff Hill (johill-lanl)]

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

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

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.

[Jeff Hill (johill-lanl)]

PS: CA sync group api provides an alternative blocking primitive for
both preemptive and non-preemptive mode ca clients. The sync group
api allows two preemptive mode threads to block independently as
long as they use independent synchronous group identifiers.