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/