At 3:30 PM +0100 7/10/01, Martin Trotter wrote:
>Is performance really such an important characteristic of volatiles ?
There isn't much use of volatiles now, so the performance of volatile
will have little or no impact on existing code.
However, most existing multithreaded Java code is broken (e.g.,
contains data races). For example, SPECjbb has a number of data races
in it. It almost every case of data race I've seen, the data race can
be fixed by declaring a single field to be volatile. For example,
double checked locking can be fixed by declaring the checked field to
be volatile.
Getting people to fix their code will be a lot easier if fixing their
code doesn't slow it down.
On a related note, Doug Lea has implemented a version of Hashtable
that allows for concurrent readers and doesn't use synchronization on
the fast read path. This implementation uses volatile to get the
required memory visibility. This implementation gives about a 15%
improvement in the performance of jess (a JVM98 benchmark program).
This is with Hotspot 1.4, which implements the "roach motel" ordering
for volatiles.
So yes, I think performance of volatiles is important. Fast volatiles
allow the creation of very high performance concurrent data
structures. Slow volatiles would deter people from using appropriate
volatile annotations to eliminate data races in their code.
>Perhaps there's a case for 'strange' variables to give load.acquire and
>st.release semantics ?
I don't think there is any way to add a new "kind" of variable. We
are stuck with three kinds:
* normal
* final
* volatile
Bill
-------------------------------
JavaMemoryModel mailing list - http://www.cs.umd.edu/~pugh/java/memoryModel
This archive was generated by hypermail 2b29 : Thu Oct 13 2005 - 07:00:33 EDT