PS: It could be done on an int, check the hashcode of toString. It also relies on a normal private field for the hashcode and a lazy calculated hash function without any additional synchronization.
But with more complex datastructures like a long/double or object graphs, I don't know if it still is safe. On Mon, Sep 13, 2010 at 2:55 PM, 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. > > > 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]. For more options, visit this group at http://groups.google.com/group/jvm-languages?hl=en.
