Re: JavaMemoryModel: The Optimistic Read Idiom and the new Java Memory Model

From: Jan-Willem Maessen (jmaessen@MIT.EDU)
Date: Mon Oct 30 2000 - 22:23:43 EST

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.


* 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

* 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.

JavaMemoryModel mailing list -

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