Re: JavaMemoryModel: Question about the semantics of volatile

From: Vijay Saraswat (
Date: Thu Mar 18 2004 - 11:21:16 EST

Bill Pugh wrote:

> On Mar 18, 2004, at 5:14 AM, Vijay Saraswat wrote:
>> CCM semantics can handle either formulation. I suspect this decision
>> will not makes a sharp separation between competing models.
>> If weak supports the common programming idioms then why not mandate
>> weak, with the justification that it requires less of the
>> implementation?
>> Best,
>> Vijay
> Because some people want to go beyond the common programming idioms.

Oh I think there is a very clear answer to that, based on Java philosophy.

The "some people" lose. Here's why.

Java is not an experimental language to "try out" things. Java is
intended to be a stable production language, that grows on you, that has
tried and tested features. It is really really important to be
conservative, particularly in brand new areas (such as this) where
research issues are not settled. Let the research communities work out
the issues in 1, 2, 5 years and then come back and change the language.

Make only the changes that you *must*. Each time that this is violated,
there is cost -- for programmers, implementers, customers.

Of course sometimes despite peoples' best intentions errors happen.
Witness the initial class loader design. But lets not consciously put in
features for which we (people on this list, larger research community)
dont have the time to do a full thorough study.

> I cited examples where the strong interpretation allows people to
> write efficient concurrent idioms that could not be implemented with
> the weak interpretation.
> The real question (to my mind) is whether or not we can cite any examples
> where the strong interpretation imposes a higher implementation cost.
> I believe that both the Treadmarks DSM implementation and IA-64 st.rel
> and ld.acq
> semantics support the strong interpretation directly.

Need to see papers, citations, proofs, claims that can be independently
verified to be technically correct. People make mistakes (particularly
in this field), relying on recollections and hasty mail messages to fix
language design issues for a language intended for stable production use
would not be my recommended approach.


JavaMemoryModel mailing list -

This archive was generated by hypermail 2b29 : Thu Oct 13 2005 - 07:01:00 EDT