People who have complaining about lack of volatile arays will be happy
to know that JSR-166 will introduce AtomicReferenceArray<T> (i.e.,
generic), AtomicIntegerArray, and AtomicLongArray. See
http://gee.cs.oswego.edu/dl/concurrency-interest/index.html
These are all part of a little "atomics toolkit" that will be in
java.util.concurrent.atomics in JDK 1.5. The basic theme here is that
Atomics are just volatiles with one additional operation,
compareAndSet (CAS), for the three types/sizes for which this is
meaningful and useful. CAS has the obvious memory model semantics of
first reading and then writing a volatile.
It was not possible to syntactically incorporate CAS into Java, so the
support for all this is a little quirky. But basically, there is a way
to use atomic versions of int, long, or reference fields and array
elements across all the kinds of programming contexts where they might
arise. The volatile-ness of AtomicXArrays falls out of this. (The
classes are, by necessity, implemented natively in JVMs. There's no
way to otherwise magically make array elements volatile.)
I'd guess that only highly-memory-model-conscious programmers will
ever use these classes, so Hans's and Sarita comments and concerns
about ordinary Java arrays still apply.
-- Doug Lea, Computer Science Department, SUNY Oswego, Oswego, NY 13126 USA dl@cs.oswego.edu 315-312-2688 FAX:315-312-5424 http://gee.cs.oswego.edu/ ------------------------------- JavaMemoryModel mailing list - http://www.cs.umd.edu/~pugh/java/memoryModel
This archive was generated by hypermail 2b29 : Thu Oct 13 2005 - 07:00:50 EDT