David,
I'm not comfortable with your informal description. It uses lots of
technical, all of which really needs to be defined:
In the context of the model, what's a "read barrier?" What's "main
memory?" What's a "write barrier?" What's a "shared variable?" What's an
"instruction involving a shared variable?" What does it mean to "reorder such
instructions across entry/exit of a
synchronised block?" I'm not really looking for answers to all of these
questions, but I believe that we need a model description that leaves far less
to the imagination.
Two things in your description make me particularly nervous:
>The basic premise of the model is as follows:
>
>"Any access by multiple threads to variables that are either non-final,
>non-volatile or not accessed under synchronisation, can lead to results
>that are surprising, if not astounding, on multi-processor systems.
It seems to me very much contrary to the spirit of Java to mention
multi-processor systems in the spec. You'll end up creating two dialects:
Java for uniprocesors and Java for multiprocessors.
>Additionally we augment the Java language to allow array entries to be
>declared 'final' or 'volatile'.
Whoa - language changes are very serious business! What syntax do you
propose for the extension? I sure hope we don't end up doing anything like
what C/C++ did to distinguish between a volatile pointer to an int and a
pointer to a volatile int. In my experience, very, very few C programmers
understood this stuff well enough to use it. I actually do like the idea of
being able to declare an array whose contents are immutable, but I'm not
hopeful about getting such a beast into the language any time soon.
Josh
-------------------------------
JavaMemoryModel mailing list - http://www.cs.umd.edu/~pugh/java/memoryModel
This archive was generated by hypermail 2b29 : Thu Oct 13 2005 - 07:00:22 EDT