My theory about why this is ok is as follows, perhaps you can see something wrong with it.
Felix DS has some synchronization after activate is called, therefore the state of the static reference is definitely written to memory. This reference field won’t change after that, since it’s (SCR) static. Any getService call on the service reference also has sufficient synchronization that it happens after the above write. Therefore any other thread which obtained the referenced service will get an object with the correct field value. Therefore any access to this possibly cached object by any thread will have the correct value. thanks david jencks > On Apr 27, 2017, at 9:33 AM, Dirk Hogan <dirk.ho...@forgerock.com> wrote: > > 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