[concurrency-interest] Synchronization question

Joe Bowbeer joe.bowbeer at gmail.com
Wed Jun 28 08:44:24 EDT 2006


On 6/28/06, Holger Hoffstätte <holger at wizards.de> wrote:
> Brian Goetz wrote:
> > And, just for completeness: synchronized write + nonsynchronized read
> > doesn't create the required happens-before, so it doesn't work.  The
> > getter in such a case isn't required to ever return anything other than
> > the default (zero) value.
>
> This made me curious. While "strictly speaking" the above behaviour might
> be correct according to the spec/revised memory model, in practice (as in
> stuff I can buy/run today) the unsynchronized read *will* succeed - maybe
> later than one might expect but it still does, simply because most people
> don't yet have transactional or distributed shared memory, and the VM is
> still pretty conservative about its write-back. So how exactly will the
> above behaviour ever come into play? Is it caused by:
> - the VM and its *implemented* cross-thread memory sync policy
> - the physical memory as implemented by the OS
> - both or something else?
>
> Are there any actual CPUs that are really that picky? T1, Azul?
>
> Somehow I get the feeling that a VM/CPU that would strictly implement the
> above behaviour - always returning the initial null for an unsynchronized
> read when done from another thread - would be less than successful on the
> market with existing Java applications. It would mean that all methods
> returning an instance variable would have to be declared as synchronized
> or the variable as volatile, effectively making both keywords (or at least
> volatile) redundant since the 'safe' behaviour might as well be the
> default. Somehow I get the feeling that this would be a second Y2K in the
> making.
>
> Another question - what exactly causes the delayed visibility of
> references or variables across threads? I'd like to learn more about the
> internals.
>
> thanks
> Holger
>
> PS: Yes, I have the book and recommend it everywhere. :)
>

AFAIK, unsynched reads can be hoisted out of loops today in the
adaptive/JIT stage.

    while (getFoo() == null)
        Thread.yield();

=>

    if (getFoo() == null)
        while(true) Thread.yield();

> Somehow I get the feeling that a VM/CPU that would strictly implement the
> above behaviour - always returning the initial null for an unsynchronized
> read when done from another thread - would be less than successful on the
> market with existing Java applications.

Just so you know, there's lengthy discussion and background
information in the JMM archives:

http://mailman.cs.umd.edu/mailman/options/javamemorymodel-discussion

--Joe



More information about the Concurrency-interest mailing list