The example I gave in my message was an attempt to reconstruct the one
in Joe Bowbeer's message.
Yes, the model in our OOPSLA paper does allow volatile operations to
be moved into a synchronization region---even in the case of the loop:
> Thread 1:
> do synchronized(this) { work(); }
> while (!stop);
As I noted in my mail, examples like these are a pretty compelling
argument for preventing volatile operations from moving into
synchronization regions.
Proposal:
* Order volatile operations with respect to locks as well as with
respect to one another. This eliminates any question of correctness
in either of Joe Bowbeer's examples.
! Require a series of volatile reads to the same location to
eventually perform a read. This allows load elimination and other
optimizations on volatiles, but permits busy waiting. Right now our
model says nothing about liveness, so this would be a first. I
remain convinced busy waiting isn't the best idea unless you're
writing real-time code, though, as too many things are likely to go
wrong.
* Allow local (or never-read) uses of volatile variables to be
eliminated without any effect on program ordering. Solve the reader
lock problem in one of three ways:
- Use a clever, yet acceptably cheap, alternative implementation
- Order regular & volatile reads
- Memory fence library (what should the semantics & granularity be?)
A trick like the last-owner test we used in the CRF paper also applies to
volatile reads, possibly looking only at last writer. It is clear in
this case that the resulting semantics looks contrived, and may have
surprising consequences.
-Jan
-------------------------------
JavaMemoryModel mailing list - http://www.cs.umd.edu/~pugh/java/memoryModel
This archive was generated by hypermail 2b29 : Thu Oct 13 2005 - 07:00:28 EDT