Hi David- I am asserting that unless the @Reference is volatile, regardless of whether it is STATIC or DYNAMIC, a data race is present.
The JMM states synchronization barriers on DISTINCT monitors have no memory effects for the references read/written within the synchronization blocks. That is stated in the first bullet point under section 17.4.4 here: http://docs.oracle.com/javase/specs/jls/se8/html/jls-17.html#jls-17.4 Here's an example demonstrating that fallacy: https://shipilev.net/blog/2016/close-encounters-of-jmm-kind/#wishful-unobserved-sync The inter-thread memory visibility of writes/reads are guaranteed only if performed when synchronized on the SAME monitor. Seeing as Felix does not expose some global monitor to synchronize on in order to guarantee the visibility of the @References it has written, looking at the code to determine the presence of 'enough synchronization barriers' does not seem to make sense. Thanks Dirk On Tue, May 2, 2017 at 11:56 AM, David Jencks <david.a.jen...@gmail.com> wrote: > I don’t understand your example or I don’t understand how your example > relates to an osgi or ds problem. > > I think you are proposing that the DS component is an http server and > starts threads etc. If so, it’s that components responsibility to make > sure its’ internal operations are thread safe, and this has little to do > with osgi or ds. > > If you are asking about osgi, for instance if the component exposes > HttpServlet and is registered with the whiteboard http service and receives > calls from it, then the whiteboard had to call getService to get the DS > component instance. In this case I think that there are plenty of > synchronization barriers in the service registry and in e.g. > SingleComponentManager.getService to assure that the view a request > thread has of the component is the same as the view the activation thread > had. > > I could be wrong about whether there are actually enough synchronization > barriers. Have you looked at the code to see? > > thanks > david jencks > > > On May 2, 2017, at 10:45 AM, Dirk Hogan <dirk.ho...@forgerock.com> > wrote: > > > > 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.a...@liferay.com> > > wrote: > > > >> On Tue, May 2, 2017 at 1:18 PM, Raymond Auge <raymond.a...@liferay.com> > >> wrote: > >> > >>> > >>> > >>> On Tue, May 2, 2017 at 1:14 PM, Raymond Auge <raymond.a...@liferay.com > > > >>> wrote: > >>> > >>>> > >>>> On Tue, May 2, 2017 at 11:46 AM, Dirk Hogan <dirk.ho...@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) > >> > >
