felix-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Neil Bartlett <njbartl...@gmail.com>
Subject Re: memory visibility of @Reference service references
Date Thu, 27 Apr 2017 17:00:44 GMT
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.hogan@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


Mime
View raw message