> -----Original Message-----
> From: owner-javamemorymodel@cs.umd.edu
> [mailto:owner-javamemorymodel@cs.umd.edu]On Behalf Of David F. Bacon
> The problem isn't with sleep. The problem is that the way
> load/read/use are defined (don't have the book at home, so I can't quote
it)
> it is completely legal and even encouraged to write code that polls a
variable
> modified by another thread without synchronization.
I don't quite understand where David is coming from on this. Under the
current JMM the examples that have been shown are not guaranteed to reflect
any updates in the variable polled without synchronisation. These variables
should either be marked as volatile or accessed under sync. And even then
some examples that assume that visibility of the flag implies visibility of
a shared object, would still be broken without new initialisation rules.
I'm not sure if David is implying that this code should work as naively
expected or whether it should be illegal to construct such code.
> I think it would break an awful lot of code to change this.
The code is already broken its just never been exercised on systems where
the break becomes apparent. The people writing these examples just don't
realise they are wrong.
These examples have been flagged as bugs for a long time now but nobody is
taking any notice - like so many bugs in the bug parade these are trivial
to fix but not high on anyone's priority list. I waited 18 months to see a
one line documentation fix!
> Unsynchronized readers are required in Java because it provides
> no read locks, only write locks.
Whilst I agree that native read/write locks, supplied through a core
library such as java.util.concurrent :) would be of great use I don't see
the relationship between a read lock and unsynchronised access. Even a
native read lock would require atomic instructions and/or memory barriers
on the MP systems where the examples would fail.
Cheers,
David Holmes
-------------------------------
JavaMemoryModel mailing list - http://www.cs.umd.edu/~pugh/java/memoryModel
This archive was generated by hypermail 2b29 : Thu Oct 13 2005 - 07:00:20 EDT