On Mon, Sep 13, 2010 at 4:10 PM, Christian Vest Hansen <[email protected] > wrote:
> On Mon, Sep 13, 2010 at 14:55, Peter Veentjer <[email protected]> > wrote: > > Hi Charles, > > > > Hmm.. afaik it still could be possible that a thread sees a mixture of > state > > not belonging to any thread at all. > > Provided the object in question is properly constructed (the `this` > reference to not escape) then the setting of the final fields of the > object happens-before the object reference is made available to the > caller. > He Christian, if it is a properly constructed immutable object (so all fields final) it should work. But as soon as one of the fields is not final, you could see freaky stuff since the publication of the object can happen before the completion of the constructor and impossible state could be observed by other threads. Luckily you can always wrap an 'unsafe' object in a final wrapper to ensure initialization safety, but will cause more stress on the cache. > And to my knowledge, object references have the same atomicity and > visibility guarantees as ints. Meaning; you cannot see a reference > where one half of the bits point to one state, and the other to > another state. > That is correct. But there are also doubles/longs. > > In summary, what Charles is doing is technically safe for his use case. > I would say: it really depends on the initialization safety of the objects being stored. If somewhere a final is removed (not needed for a normal immutable object), subtle problems could be introduced. > > > > On Mon, Sep 13, 2010 at 2:50 PM, Charles Oliver Nutter < > [email protected]> > > wrote: > >> > >> I'm looking for a clear answer on this. > >> > >> I have various places in JRuby where I've been hassled for not using > >> volatile fields. Specifically, on some of the method caches. These > >> caches have non-volatile fields referencing immutable tuples of [class > >> ID, method], and it's not important to me that all threads have the > >> same view of those fields. In fact, it's almost better that they > >> don't, since different threads will often be executing different code > >> and encountering different types. > >> > >> So, official verdict: if I don't care about different threads having a > >> consistent view of a field, there's no reason I need it to be > >> volatile, right? > >> > >> - Charlie > >> > >> -- > >> You received this message because you are subscribed to the Google > Groups > >> "JVM Languages" group. > >> To post to this group, send email to [email protected]. > >> To unsubscribe from this group, send email to > >> [email protected]<jvm-languages%[email protected]> > . > >> For more options, visit this group at > >> http://groups.google.com/group/jvm-languages?hl=en. > >> > > > > -- > > You received this message because you are subscribed to the Google Groups > > "JVM Languages" group. > > To post to this group, send email to [email protected]. > > To unsubscribe from this group, send email to > > [email protected]<jvm-languages%[email protected]> > . > > For more options, visit this group at > > http://groups.google.com/group/jvm-languages?hl=en. > > > > > > -- > Venlig hilsen / Kind regards, > Christian Vest Hansen. > > -- > You received this message because you are subscribed to the Google Groups > "JVM Languages" group. > To post to this group, send email to [email protected]. > To unsubscribe from this group, send email to > [email protected]<jvm-languages%[email protected]> > . > For more options, visit this group at > http://groups.google.com/group/jvm-languages?hl=en. > > -- You received this message because you are subscribed to the Google Groups "JVM Languages" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/jvm-languages?hl=en.
