On Thu, Apr 21, 2011 at 2:36 PM, Clifford Heath <no / spam.please.net> wrote: > On 04/21/11 21:28, Robert Klemme wrote: >> >> Please keep in mind that in a multithreaded environment there is >> synchronization overhead. ¨Β σομυτιοξ γουμυσαξ ΑτονιγΒοομεα> > Oh get real. This is a single variable which may, during the course of > a single execution, *once* change from false to true. In multithreaded applications the change frequency is not important. What's important is the access frequency (read and write) because even if memory does not change access needs to be guarded by proper synchronization means for an application to work correctly in light of multiple threads. > In so doing, it > enables a slightly more conservative approach to compatibility for one > small side-effect of a shortcut, which probably doesn't even matter to > the application, and which is almost certainly set by the one thread > that cares about that side effect. It *so* doesn't need to be synchronised. As I said, it does not need to be guarded by "synchronized". But it needs to be at least volatile for multithreaded applications to work properly - otherwise you might see odd effects. For each *access* (that is write *and* read) there needs to be a memory barrier which essentially means that modified thread local memory must be published so other threads can see it. Since many pages might be modified and there is NUMA this can actually have a measurable cost. The JVM memory model is a fascinating topic but significantly more complex than one might be inclined to believe at first. Kind regards robert -- remember.guy do |as, often| as.you_can - without end http://blog.rubybestpractices.com/