Hi Neil-
I was not so worried about the happens-before relationship between
setting the @Reference and activating the component. This relationship
could be provided by the memory visibility guarantees of the program
order defined in the JMM, provided @Reference set and component
activation occurred in the same thread.
I was more worried about some other thread (e.g. client request)
hitting this component, and, in the process, dereferencing the
@Reference, as this will involve inter-thread memory visibility, and
as such, a synchronization action to ensure that a memory read sees
the state written by OSGi thread which wrote the @Reference.
Thanks
Dirk
The Declarative Services spec requires that there is a happens-before
relationship between SCR setting the field and activating the component
instance — see OSGi Compendium 6.0.0 section 112.3.8.1.
There are various ways of achieving this under the Java Memory Model. For
example the SCR implementation can use internal synchronized blocks.
Regards,
Neil
> On 27 Apr 2017, at 17:33, 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
