Re: JavaMemoryModel: Re: JMM problems with latch or copy-on-write?

From: Joseph Bowbeer (
Date: Fri Mar 30 2001 - 12:58:52 EST

The execution sequence I provided wasn't a program. To make a sample
program, simply put thread2 in a loop:

    while (!initialized) {
        synchronized(obj) { }

This sample merely illustrates the kind of background synchronization that
exists in almost every Java application.

----- Original Message -----
From: "Jeff Bogda" <>
To: "Java Memory Model" <>
Sent: Friday, March 30, 2001 9:43 AM
Subject: RE: JavaMemoryModel: Re: JMM problems with latch or copy-on-write?

> > Specifically, transmission is guaranteed if the initializing thread
> > subsequently releases a lock or writes to a volatile variable *and* the
> > reading thread subsequently acquires the same lock or reads the same
> > volatile variable.
> >
> > Example, in sequence:
> >
> > thread 1: initialized = true
> > thread 1: synchronized(obj) { }
> > thread 2: synchronized(obj) { }
> > thread 2: assert(initialized == true)
> Eep! That won't work, because in our model (again, can't speak for CRF),
> useless synchronization can be optimized away. Plus, oh, your next point.

One may argue that this synchronization is not useless because it makes the
value "true" for "initialized" visible to thread 2. However, I agree with
Jeremy (although I am not sure where in his paper he states this) and feel
that these synchronized blocks (like all empty synchronized blocks) are

As it stands now, there is nothing that prevents thread 2 from executing
before thread 1, regardless of "initialized"'s being volatile or not. Thus,
in some executions the assertion will fail. If the programmer wants thread 2
to always execute after thread 1, then he needs additional thread control
(such as wait/notify, Thread.start(), or spinning on a volatile). And if he
has that, then the value "true" will propagate to thread 2 without the empty
synchronized blocks.

In short, I'd say that a program that relies on the synchronization of obj
to see values has a programming error.


JavaMemoryModel mailing list -

JavaMemoryModel mailing list -

This archive was generated by hypermail 2b29 : Thu Oct 13 2005 - 07:00:31 EDT