Possible language changes

[Doug Lea]

> My concerns are: (1) Fence instructions are expensive, roughly 100 cycles, =
> 
> (2) Full acquire/release semantics are not needed in most accesses to=20
> volatile variables in many useful algorithms. I'll try to give some=20
> examples below. (3) Once the language gives a strong guarantee, it is=20
> almost impossible to take it back. So, I prefer giving minimal guarantees.
> 
> My preference is to separate memory ordering from volatility and=20
> atomicity.
> 

My initial thoughts (in the original proposal) were to give "volatile"
strong semantics, but to provide methods in the atomicX classes that
provide more flexible barriers. I still think this is a good idea.
(It's an extension of what we did in Java.) People developing carefully
crafted nonblocking algorithms would have to use atomics rather than
volatile, but there is no penalty for doing so
except for more awkward syntax . These classes have no virtual methods
and only hold a single (int, long, pointer), so there is no space
or time overhead.

One advantage is that people doing ordinary things like
double-checked locking can make their code work simply by declaring
fields volatile, without requiring a deep knowledge of ordering and
barriers (which few programmers know much about). Also, as in Java,
compilers can optimize away some of these barriers. (See the table
near the end of my http://gee.cs.oswego.edu/dl/jmm/cookbook.html --
The Sun (and I think JRockit) server JVMs actually do most of these
on x86 and sparc.)

But if you are smarter than the compiler and need manual control, you
can use atomic classes.

Can you live with this?

If not, can you think of a reasonable alternative?

If so, there are still some details to be worked out on the form
and semanitcs of some of the methods on atomics, but it seems
straightforward. (For example, should there be a method that performs
a not-necessarily-atomic read on an atomic?)

-Doug