RE: JavaMemoryModel: A new box for the Java Memory model

From: David Holmes (dholmes@ics.mq.edu.au)
Date: Tue Nov 09 1999 - 16:36:44 EST


Hi Josh :-)

> -----Original Message-----
> From: Joshua Bloch [mailto:jbloch@eng.sun.com]
> I'm not comfortable with your informal description. It uses lots of
> technical, all of which really needs to be defined:

Of course - but I think that it conveys the gist of things.

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

Well gee - I didn't expect it to get published in its current form ;-)

The idea was to present a programmers view of the model so that we all get
a feel for what is being suggested. Defining that model in more concrete
terms would have to be done before it could be put forward as a proposal.
But lets consider the basic features of the model before we worry about
defining a precise form.

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

Remove the reference to multi-processor - there are probably surprising and
astounding things that could happen on a uniprocessor too. There was no
intent to say that you can get away without synchronisation on a
uniprocessor.

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

You are probably one of the few people on the list who could actually find
out why this wasn't originally in the language. I'd be curious to find out.
;-)

As I said in my other response making the change to the language is a
secondary concern - the current limitation would just become much more
obvious if the enhanced volatile and final semantics were taken up.
Additionally, given it requires no new keywords and could not possibly
break any existing code I think (ugly syntax aside) that such a language
change would be trivial to make (in practice if not in process).

All that aside do you have any real comments on the proposed enhancements
to volatile and final?

Cheers,
David

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