[concurrency-interest] Synchronization question

Holger Hoffstätte holger at wizards.de
Wed Jun 28 05:32:18 EDT 2006

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

Another question - what exactly causes the delayed visibility of
references or variables across threads? I'd like to learn more about the


PS: Yes, I have the book and recommend it everywhere. :)

More information about the Concurrency-interest mailing list