[concurrency-interest] concurrency puzzle
alarmnummer at gmail.com
Mon Sep 11 03:44:34 EDT 2006
But what about the behaviour of the synchronized statement? If a lock
is obtained, local memory (for that thread) is invalidated and the
next read is going to access main memory.
That is why the assignment of x=20 could get lost. If the x=20 isn't
written to main memory (and in this case there is no need to) but only
to cache, the value is 'dropped' when the cache is invalidated.
Is this correct? I'm trying to understand the memory behaviour of the
synchronized statement: that is the reason why I made this example.
On 9/11/06, Jeremy Manson <jmanson at cs.umd.edu> wrote:
> This is off list, as it is probably a little more obscure than most
> people will want to tackle.
> David Holmes wrote:
> > Wow! That is a very subtle distinction. I'm not sure there are any practical
> > consequences arising from it but I find it disconcerting to have this
> > difference.
> I think it is the least disconcerting of the possible alternatives:
> If we picked the semantics of the variable initializer, and gave it to
> the default write, then the default write wouldn't be guaranteed to be
> seen by every thread that reads a reference to that object via a data
> race. You can't see a garbage value, so what value do you see?
> If we picked the semantics of the default write, and gave it to the
> variable initializer, then writes made in constructors would have to
> propagate to every thread that sees a reference to the object. This
> would have a pretty big performance impact.
> If we picked the semantics of the default write, and gave it to only the
> variable initializers that write out default values, then you have far
> worse problems, because you are
> a) creating yet another obscure corner case for Java;
> b) in practice, relying on the compiler or virtual machine to detect
> and remove writes of the default value in a variable initializer, so
> that other threads don't see them out of order. Not only is this not
> always possible, but it is bad for the spec to require certain
> optimizations to occur; and
> c) (and possibly worst of all) changing the memory semantics based on
> which value is written out to a field.
> These are all straw men, but I can't really think of a better "fifth
> way" to do this.
> Concurrency-interest mailing list
> Concurrency-interest at altair.cs.oswego.edu
More information about the Concurrency-interest