Experimental Physics and
Industrial Control System

Dirk Zimoch <[email protected]> · Fri, 21 May 2010 14:40:58 +0200

Hi Ben,
Locking and/or re-reading might be possible for SNL code accessing the
variables but what about escaped C-Code? You probably have to take the
lock before escaping to C but then nobody is allowed to do blocking
things in that code.
A layer of "shadow variables" might be safe. CA updates the shadow copy
at any time while the state code executes. Only during the state
transition and inside pvGet the data is transfered to the "user copy".
(any back inside pvPut). CA has to be locked out only during these copy
actions. Of course that requires twice the amount of memory for
variables plus some time for the additional copy.
Concerning double: On the new PPC 500v2 core it takes indeed two
assembler instructions to load or store a double. Thus doubles are
non-atomic.
By the way, I think arrays are already unsafe on the server! If the
array record processes and updates the array at the same time as it is
sent on the network by CA, the user gets a half old/hald new array. This
is because only the pointer to the array is put into the queue for the
CA thread, not the array data itself. (I am happy if somebody could
prove me wrong.)
Best regards,
Dirk
Benjamin Franksen wrote:

On Friday 21 May 2010, Andrew Johnson wrote:

On Thursday 20 May 2010 17:53:04 Benjamin Franksen wrote:

This bug must have been in the sequencer for a long, long time,
probably right from the beginning.

I'm not convinced it's quite as bad as you think; I suspect it derives
 from R3.14.x when Jeff introduced the ca_enable_preemptive_callback
 option.  Before this time the CA library never got a chance to process
 network messages unless you called it using ca_pend_event() or
 ca_pend_io() so the callbacks would only run when the thread was inside
 the CA library.

Unfortunately, pre-3.14 versions are affected, too, see below.
Hmm, that doesn't necessarily work with multiple state sets though, I

wonder if CA supported sharing CA contexts back then?

It did, this is what the ca_import routine was for.
You are right that if you use one single task and
ca_disable_preemptive_callback (or, equivalently, the old
ca_task_initialize), then there is no problem. However, even the old 1.9.x
sequencer releases use an extra auxiliary task to initialize CA, and a
separate task for each state set taht calls ca_import. The auxiliary task is
the only place where ca_pend_event is called. This means all callbacks will
be executed in the task context of the auxiliary task, and (I checked it)
there are no locks taken when the callback copies the data into the program
variable.
So, the only difference is that in the old versions it is the sequencer's
own task, while in later versions it is a (hidden) CA internal task.
Cheers
Ben

Experimental Physics and Industrial Control System

Experimental Physics and
Industrial Control System