Bill Pugh writes:
> We haven't yet seen any examples where you get into trouble
> by allowing the reordering of:
>
> monitor exit followed by a volatile read
>
Couldn't it mess-up someone's plans to use a volatile as a spin-lock?
(gack!)
Initially:
volatile boolean consumed = true;
Thread 1:
while (true) {
synchronized(this) {
if (consumed)
work();
consumed = false;
}
}
while (!consumed) { /* wait */ }
}
Thread 2:
while (true) {
synchronized(this) {
if (!consumed) {
consumeWork();
consumed = true;
}
}
}
Here, thread 2 is using the volatile flag 'consumed' to signal thread 1 to
stop waiting and do some more work. If the read of 'consumed' in thread 1 is
moved into the synchronized block, then the program deadlocks.
> However, to keep the semantics symmetric, I think we should
> prohibit any _observable_ reordering of a monitor exit followed
> by a volatile read.
Good.
-- Joe Bowbeer------------------------------- JavaMemoryModel mailing list - http://www.cs.umd.edu/~pugh/java/memoryModel
This archive was generated by hypermail 2b29 : Thu Oct 13 2005 - 07:00:32 EDT