Dirk,
But this is why the happens-before relationship is important. The component is
not published as a service until after activation, therefore no other thread
can obtain visibility in order to “hit” it until after the references are bound.
For this reason, static @Reference fields do not need to be volatile.
Regards,
Neil
> On 1 May 2017, at 22:05, Dirk Hogan <dirk.ho...@forgerock.com> wrote:
>
> 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
