Experimental Physics and
Industrial Control System

"Jeff Hill" <[email protected]> · Fri, 6 Sep 2002 12:03:06 -0600

Synchronization of the read or write request
dispatch on the client side is an interesting
idea which might be appropriate to environments
other than just Java.

The CA synchronous groups facility provides write
completion synchronization capabilities for
independent groups of PVs, but does not address
synchronized client side dispatching of these
write requests.

However the CA synchronous group facility could be
enhanced to include a special type of deferred put and
get requests that are not sent until a special sync
group "flush deferred requests" call is made. As
Tom mentions, some sort of specialized locking
would be required if we were to prevent other threads
from flushing, and or inserting requests into, the CA
output queue while all of the requests were being
delivered to the socket. Perhaps this lock would be
best implemented at a low level to prevent raw CA
protocol generated by CA background activities from
being interleaved with this synchronized batch of
requests.

Of course, despite the fact that all of the requests
were handed off to the socket at almost the same time,
its more challenging to guarantee that they will be sent
by the client os and received by the server os together
given the types of networks that we usually use. I seem
to recall that the SNS network devices have some interesting
prioritized virtual circuit options.

The client specified server dispatch priority capabilities
in the R3.14 client library will help. Especially,
if they were further enhanced to request a higher priority
virtual circuit from the OS, and ultimately the network
infrastructure.

Jeff

> -----Original Message-----
> From: Tom Pelaia [mailto:[email protected]]
> Sent: Wednesday, September 04, 2002 3:11 PM
> To: Epics Tech-Talk
> Subject: JCA thread safety
>
> Hi,
>
> We are using JCA within our accelerator framework.  Has anyone dealt
> with thread safety issues relating to JCA?  In particular, I am
> concerned with switching between asynchronous and synchronous modes of
> PendEvent.  Sometimes we would like to write values immediately, while
> other times we would like to package changes in a single batch.  These
> operations may take place concurrently in different threads.
>
> The solution that we are considering here is to leave PendEvent in
> synchronous mode and write a higher level wrapper to coordinate batch
> writes.  For example, value requests could be registered with the
> coordinator.  The user then sends a request to push the results to the
> server and the coordinator wraps requests into a single pend event.
In
> order to prevent conflicts with other threads, we would have to
provide
> a lock to synchronize the pend events.
>
> Has anyone already built such a solution?  Is there a mechanism to use
> JCA in a thread safe way?  Are there plans for a thread safe version
of
> JCA in the future?
>
> Additionally, it seems that within PendEvent.java, the variable m_exit
> should be declared volatile to ensure that the while loop in the run()
> method exits immediately when exit() is called.
>
> thanks,
> -tom pelaia
>
> --
> Tom Pelaia
> SNS Project, 701 Scarboro Road, MS-6473, Oak Ridge, TN 37831
> phone: (865) 574-6421, fax: (865)574-6617

Experimental Physics and Industrial Control System

Experimental Physics and
Industrial Control System