felix-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Dirk Hogan <dirk.ho...@forgerock.com>
Subject Re: memory visibility of @Reference service references
Date Tue, 02 May 2017 17:45:17 GMT
Hi Raymond-
Assume Felix does it's thing: sets all @References, activates all
components, publishes all services. It has resolved all dependencies, and
set references accordingly.

Thus, in the example above, myOSGiComponent has its @Reference to
SomeOtherOSGiService resolved - Felix has set this reference. At the
conclusion of the activate method, myOSGiComponent has exposed some
functionality via http, even successfully dereferenced myOSGiComponent, and
now requests start to come it, serviced by the http-server's thread-pool.
Part of servicing this request involves dereferencing (reading) the
@Reference myServiceReference, which, I agree has been set (written) by a
Felix thread.

The point of the Java Memory Model is that memory state, including
references, read and written across threads, do not have to have
determinate state, unless there is a Synchronization Action which ensures
that the state written by thread A is visible to any other thread - a
volatile reference provides such a Synchronization Action. So code in
myOSGiComponent activate method can successfully dereference the
SomeOtherOSGiService reference, because the same thread which set the
reference is calling activate. But this does NOT mean that another thread,
reading the SAME reference, will see a properly initialized reference.

Again, this should be self-evident, and the various rules of the JMM model
are defined in section 17.4 of the Java Language Specification. If it is
not clear, then an understanding if the JMM is required. This understanding
can be gained by reading the JLS, reading the links above, the chapter
in *Concurrency
in Practice* on the JMM,  or http://gee.cs.oswego.edu/dl/cpj/jmm.html
provides a good intro.

The bottom line: memory state, including references, shared among multiple
threads can have indeterminate state when written/read, unless explicit
steps, defined in the JMM, are taken to ensure this visibility and thus
coherent state. This is not an opinion.

Thanks

Dirk



On Tue, May 2, 2017 at 10:23 AM, Raymond Auge <raymond.auge@liferay.com>
wrote:

> On Tue, May 2, 2017 at 1:18 PM, Raymond Auge <raymond.auge@liferay.com>
> wrote:
>
> >
> >
> > On Tue, May 2, 2017 at 1:14 PM, Raymond Auge <raymond.auge@liferay.com>
> > wrote:
> >
> >>
> >> On Tue, May 2, 2017 at 11:46 AM, Dirk Hogan <dirk.hogan@forgerock.com>
> >> wrote:
> >>
> >>> But no similar guarantee applies when another thread hits the
> >>> component,
> >>>
> >>
> >> I believe the discussion boils down to why you believe the above is
> >> possible?
> >>
> >> If SCR has not yet made the component available to other threads (which,
> >> to my knowledge, it only does by registering it as a service to the
> service
> >> registry) how can _another_ thread access the component at all?
> >>
> >> I don't even see a way for components within the same DS bundle to
> >> interact with each other other than via the service registry because
> >> @Reference only works through the registry.
> >>
> >
> > Correction, components could interact with each other via the
> > ComponentContext.. but I guess we'd have to know if that's part of your
> use
> > case.
> >
>
> Actually, no, it's not even possible via the ComponentContext. It only
> allows access to Services.
>
> >
> > - Ray
> >
> >
> >>
> >> Please, can you explain in more detail what case might allow for the
> >> above? Because I believe the assumption is that it's not currently
> >> possible. Certainly there could be a bug and I'm certain everyone would
> >> want to see that fixed.
> >>
> >> --
> >> *Raymond Augé* <http://www.liferay.com/web/raymond.auge/profile>
> >>  (@rotty3000)
> >> Senior Software Architect *Liferay, Inc.* <http://www.liferay.com>
> >>  (@Liferay)
> >> Board Member & EEG Co-Chair, OSGi Alliance <http://osgi.org>
> >> (@OSGiAlliance)
> >>
> >
> >
> >
> > --
> > *Raymond Augé* <http://www.liferay.com/web/raymond.auge/profile>
> >  (@rotty3000)
> > Senior Software Architect *Liferay, Inc.* <http://www.liferay.com>
> >  (@Liferay)
> > Board Member & EEG Co-Chair, OSGi Alliance <http://osgi.org>
> > (@OSGiAlliance)
> >
>
>
>
> --
> *Raymond Augé* <http://www.liferay.com/web/raymond.auge/profile>
>  (@rotty3000)
> Senior Software Architect *Liferay, Inc.* <http://www.liferay.com>
>  (@Liferay)
> Board Member & EEG Co-Chair, OSGi Alliance <http://osgi.org>
> (@OSGiAlliance)
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message