> In particular, it is legal to reorder a load/store and a following
> monitorenter, and it is legal to reorder a monitorexit and a
> following load/store. (In other words, you can move stuff from
> outside a synchronized block inside the block, but you can't move
> stuff from inside to outside.
One would expect however that more general code motion is not allowed. For
example, moving a method invocation from outside a synchronized block into
the synchronized block - try figuring out where that deadlock came from ;-)
Thinking further I am not at all happy with what you have suggested.
Thinking back to earlier suggestions of adding explicit read/write memory
barrier operations to the language, such proposals would seem to rely on the
fact that no code motion occurs across those barriers. I would expect the
same code motion restrictions to apply to the implicit barriers in
synchronized blocks. Someone else has told me that they believe POSIX
semantics do indeed imply code motion barriers regarding mutex acquisition
and release. This would seem the most sensible thing to me. Of course code
motion could be allowed if the motion can be shown to be
unobservable/benign/harmless.
David
-------------------------------
JavaMemoryModel mailing list - http://www.cs.umd.edu/~pugh/java/memoryModel
This archive was generated by hypermail 2b29 : Thu Oct 13 2005 - 07:00:25 EDT