On 23 Jul 2010, at 10:09, Mircea Markus wrote:
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?
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?
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
> 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
--
Manik Surtani
manik(a)jboss.org
Lead, Infinispan
Lead, JBoss Cache
http://www.infinispan.org
http://www.jbosscache.org