I have been puzzled about the visibility of references written/read across
threads in Felix.
Scenario:
public class myOSGiComponent {
@Reference
SomeOtherOSGiService myServiceReference;
public void activate(ComponentContext cc) {
// myServiceReference will be set - use it to initialize other
dependencies, etc
}
public void clientRequestViaEmbeddedJetty() {
myServiceReference.foo();
}
The bottom line is that a STATIC reference does not have to be volatile. I
can see that the write to myServiceReference is guaranteed to be visible in
the activate method, provided that same Felix thread which set
myServiceReference invokes activate, and thus the visibility is guaranteed
by program order (17.4.3 of the Java Language Spec).
However, in the absence of the synchronization action provided by e.g. a
volatile @Reference declaration, I do not see how Felix can provide a Java
Memory Model compliant guarantee that myServiceReference will be visible in
clientRequestViaEmbeddedJetty, as the thread which set the reference, and
the thread which invokes clientRequestViaEmbeddedJetty, will be distinct.
In the absence of a volatile @Reference declaration, there is no
synchronization action (17.4.2 of JLS) which would guarantee that the
reference write is visible to the reference read, as they are being
performed by distinct threads.
Perhaps an explanation as to why a DYNAMIC @Reference does need to be
volatile would be helpful - e.g. why does component
de-activation/re-activation provide memory visibility guarantees for STATIC
references?
Thanks
Dirk
