I think the JMM allows read reordering which might still be an issue (should you perform multiple reads and expect later reads return newer values).
With kind regards Ben On 13 Sep., 18:49, Charles Oliver Nutter <[email protected]> wrote: > The objects in question are fully immutable with all final fields, so > it sounds like I'm good to go. > > On Monday, September 13, 2010, 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. > > > 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. > > > In summary, what Charles is doing is technically safe for his use case. > > >> 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]. > >>> 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. > > > -- > > 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]. > > For more options, visit this group > > athttp://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.
