I always grab a local reference to the objects in question so that should be fine.
On Monday, September 13, 2010, Ben Schulz <[email protected]> wrote: > 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. > > -- 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.
