RE: JavaMemoryModel: Holub's Rules to Live By

From: Paul Jakubik (
Date: Thu Jun 29 2000 - 10:54:32 EDT

I agree with Bill. If you are not synchronizing on the same monitor, then
there is no guarantee on where one thread's memory barriers fall with
respect to the other thread's memory barrier. When you synchronize on the
same monitor, the race is resolved.

What makes Holub's rule misleading is wording it in terms of ensuring data
reaches main memory. In the end the concern is visibility between threads
and for that his rule is necessary.

I am left with one question. Is there a way to guarantee the order that two
threads access a particular variable, both synchronizing on a monitor, but
not on the same monitor? I think all the practical ways of doing this are
covered by other rules.


-----Original Message-----
From: Bill Pugh []
Sent: Thursday, June 29, 2000 8:33 AM
To: Tom Cargill;
Subject: Re: JavaMemoryModel: Holub's Rules to Live By

At 6:29 AM -0600 6/29/00, Tom Cargill wrote:
>I'm reading Allen Holub's 'Taming Java Threads'
>presentation from the recent JavaOne:
>On pages 17 and 18 he presents 7 "Rules to Live By."
>The spirit is right, but I question some of the details.
>The 4th rule (top of p. 18) is too strong, because it
>requires that both threads sync on the same lock.
>Is there expert concensus on the validity of these rules?

I believe that rule is correct and necessary.

I have yet to find any compelling and correct synchronization idioms
that not involving synchronizing on the same monitor. Most attempts
to do so wrong, in either obvious or subtle ways. If you can come up
with such a compelling example, I would be very interested in looking
at it.

More importantly, I am proposing changes to the Java Memory Model
that codify this rule into the spec. This change will allow a number
of compiler optimizations, such as the complete elimination on locks
on thread local objects.

So if you have compelling examples of how you would want to
communicate between threads by synchronizing on different monitors,
they should be discussed ASAP.

JavaMemoryModel mailing list -
JavaMemoryModel mailing list -

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