You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
This issue discusses how pvaClient (both C++ and Java) should connect to a channel.
In particular how to manage locking.
Connection involves the following methods.
channelCreated - pvAccess callback
channelStateChange - pvAccess callback
issueConnect - pvaClient method
waitConnect - pvaClient method
issueConnect, via a channelProvider, makes a call to createChannel.
As a result of this call channelCreated is always called and channelStateChange may be called.
The channel may or may not already be connected when channelCreated is called.
Sometime after issueConnect returns waitConnect is called.
The connection may already be complete but if not then pvaClient must wait until channelCreated or channelStateChange
is called and either shows success or failure.
Both pvAccess and pvaClient have internal variables that must be protected by a locking mechanism.
I think then logic is similar for both the Java and C++ implementations of pvaClient except for waitConnect.
The Java implementation is:
public Status waitConnect(double timeout)
{
if(isDestroyed) throw new RuntimeException("pvaClientChannel was destroyed");
if(channel.isConnected()) return channelConnectStatus;
lock.lock();
try {
long nano = (long)(timeout*1e9);
waitForConnect.awaitNanos(nano);
} catch(InterruptedException e) {
Status status = statusCreate.createStatus(StatusType.ERROR,e.getMessage(), e.fillInStackTrace());
return status;
} finally {
lock.unlock();
}
return channelConnectStatus;
}
NOTES
channel.isConnected() is called without locking. If called with lock held then deadly embrace.
channel.isConnected is synchronized method in pvAccessJava
Looks like extra wait can happen if connection callback occcurs after isConnected and lock.lock
The C++ implementation is:
Status PvaClientChannel::waitConnect(double timeout)
{
{
Lock xx(mutex);
if(isDestroyed) throw std::runtime_error("pvaClientChannel was destroyed");
if(channel->isConnected()) return Status::Ok;
}
waitForConnect.wait(timeout);
return channelConnectStatus;
}
NOTES:
channel->isConnected()) is called with lock held
waitForConnect.wait(timeout) is called with no lock held
Looks like extra wait can happen if connection callback occcurs after mutex is unlocked and waitForConnect
NOTE: locking in Java is NOT like locking in C++.
SO WHAT TO DO?
Matej,
Any ideas?
The following are the Java and C++ implemetation of the methods discussed above.
channelConnect
This issue discusses how pvaClient (both C++ and Java) should connect to a channel.
In particular how to manage locking.
Connection involves the following methods.
issueConnect, via a channelProvider, makes a call to createChannel.
As a result of this call channelCreated is always called and channelStateChange may be called.
The channel may or may not already be connected when channelCreated is called.
Sometime after issueConnect returns waitConnect is called.
The connection may already be complete but if not then pvaClient must wait until channelCreated or channelStateChange
is called and either shows success or failure.
Both pvAccess and pvaClient have internal variables that must be protected by a locking mechanism.
I think then logic is similar for both the Java and C++ implementations of pvaClient except for waitConnect.
The Java implementation is:
NOTES
The C++ implementation is:
NOTES:
NOTE: locking in Java is NOT like locking in C++.
SO WHAT TO DO?
Matej,
Any ideas?
The following are the Java and C++ implemetation of the methods discussed above.
pvaClientJava
pvaClientCPP
The text was updated successfully, but these errors were encountered: