Hi, I have this problem with the the dependency injection fwk in infinispan: many times I'd like to declare the injected dependencies as final fields in order to take advantage[1] of "final" semantics in Java's memory model. I cannot/don't know how to do that, can I annotate an constructor with @Inject? If not I think that would be useful. [1] @Inject methods are called by the thread that starts the CM. The injected dependencies are cached as local fields and will be accessed by a different application thread. So they'd need volatile/synchronise for proper publishing: afaik volatile is less performant that publishing with final. wdyt? Cheers, Mircea _______________________________________________ infinispan-dev mailing list infinispan-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/infinispan-dev

On 22 Jul 2010, at 19:07, Manik Surtani wrote: > They can't be final. The whole point of injecting stuff is that components go through a lifecycle: > > 1) Configure. This is where components are created and wired together. > 2) Start. > > Now in between 1 and 2, if someone still has a reference to the Configuration instance and changes some stuff, these changes would need to be reflected in the runtime. changes stuff means it changes the Configuration object itself or some of its attributes?

> Which means some components may need to be re-injected with different implementations. > > In terms of safe publishing, you can consider this safe since in the start method of the ComponentRegistry, internal volatile fields (including some locks) are touched, which means a JMM fence [1] is crossed. Afaik safe publishing would only happen if *same* variables are touched by the user's thread accessing the object, is that the case?

> So even non-volatile variables would be properly published by this time since all out-of-order operations need to complete for the fence. > > Now normally this would be considered hackish since subsequent writes to the variables in question may not be published properly, however we ensure that the ComponentRegistry is the only component capable of injecting stuff, and the CR will make sure there is a fence every time. > > HTH > Manik > > [1] http://en.wikipedia.org/wiki/Memory_barrier > > > On 22 Jul 2010, at 17:22, Mircea Markus wrote: > >> Hi, >> >> I have this problem with the the dependency injection fwk in infinispan: many times I'd like to declare the injected dependencies as final fields in order to take advantage[1] of "final" semantics in Java's memory model. I cannot/don't know how to do that, can I annotate an constructor with @Inject? If not I think that would be useful. >> >> [1] @Inject methods are called by the thread that starts the CM. The injected dependencies are cached as local fields and will be accessed by a different application thread. So they'd need volatile/synchronise for proper publishing: afaik volatile is less performant that publishing with final. >> >> wdyt? >> >> Cheers, >> Mircea >> _______________________________________________ >> infinispan-dev mailing list >> infinispan-dev(a)lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/infinispan-dev > > -- > Manik Surtani > manik(a)jboss.org > Lead, Infinispan > Lead, JBoss Cache > http://www.infinispan.org > http://www.jbosscache.org > > > > > > _______________________________________________ > infinispan-dev mailing list > infinispan-dev(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/infinispan-dev _______________________________________________ infinispan-dev mailing list infinispan-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/infinispan-dev

On 23 juil. 2010, at 11:33, Manik Surtani wrote: > > Piggybacking is a valid strategy and is used in some core JDK constructs including AbstractQueuedSynchronizer, which is used to build locks, etc. See Java Concurrency in Practice, section 16.1.4: > > http://codeidol.com/java/java-concurrency/The-Java-Memory-Model/What-is-a... > > More fun reading: > > http://gee.cs.oswego.edu/dl/jmm/cookbook.html You've just killed Mircea's productivity for the next two weeks at least. Good job! I guess that's a rite of passage ;)

>>> In terms of safe publishing, you can consider this safe since in the start method of the ComponentRegistry, internal volatile fields (including some locks) are touched, which means a JMM fence [1] is crossed. >> Afaik safe publishing would only happen if *same* variables are touched by the user's thread accessing the object, is that the case? > > Piggybacking is a valid strategy and is used in some core JDK constructs including AbstractQueuedSynchronizer, which is used to build locks, etc. See Java Concurrency in Practice, section 16.1.4: > > http://codeidol.com/java/java-concurrency/The-Java-Memory-Model/What-is-a... > > More fun reading: > > http://gee.cs.oswego.edu/dl/jmm/cookbook.html Piggybacking still requires a sync/volatile variable to be touched by both threads in order for the publishing to to be correct (int the AbstractQueueSynchronizer/FutureTaks example, a volatile variable is set to null when reading/writing state, just to enforce happens-before). To be more specific, here the safe publishing issue that concerns me: T1 creates the Cache on DCM.getCache(). This calls @Inject method on CacheDelegate that would set CacheDelegate.invoker::InterceptorChain. N.B. invoker is not final nor volatile! T2 calls CacheDelegate.put, which uses the invoker field set by T1. What guarantee do we have that invoker was correctly published by T1 and seen by T2?

Looking at the code, the safe publishing takes place in DefaultCacheManager.caches field: this is CHM where T1 added the cache and T2 got it from - so we're safe (published)!

One more detail, in the same class DefautlCacheManager.globalComponentRegistry doesn't seem to be correctly published (it is not a immutable object as well): this is created by T1 on new DCM and read by T2 when a Cache is instantiated, with no happens-before in between. I think we should declare it volatile.

> Cheers, Mircea _______________________________________________ infinispan-dev mailing list infinispan-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/infinispan-dev