Re: JavaMemoryModel: Schedule for changing the JMM

From: Joseph Bowbeer (jozart@csi.com)
Date: Sat Jan 22 2000 - 18:52:32 EST


----- Original Message -----
From: "Doug Lea" <dl@altair.cs.oswego.edu>
To: "Joseph Bowbeer" <jozart@csi.com>
Cc: <javaMemoryModel@cs.umd.edu>
Sent: Thursday, January 20, 2000 10:44 AM
Subject: JavaMemoryModel: Re: Schedule for changing the JavaMemoryModel

>
> > According to your schedule, the JMM JSR won't be announced until a month or
> > two *after* public review of RTSJ has closed. I urge everyone to checkout RTSJ
> > while public review is still open.
> >
> > http://www.rtj.org/public/
>
> Perhaps you (Joe) could write something that conveys a sense of the
> concerns of the people on this mailing list? Since we are not
> otherwise any kind of organized group, we cannot do much more than
> that.
>
> I think there are only a few basic issues with respect to JMM:
>
> * The special RawMemoryAccess mode must act like volatile.
> (These are methods, not direct accesses, so might be tricky
> to phrase this requirement just right.)
>
> * The RTJ spec should clearly state that the standard memory rules
> (i.e., ch17 or its revision) hold for all other special categories
> of memory. (Although I wonder if any other special initialization
> guarantees are intended here?)
>
> * Asynch Event handlers must be written as if each triggering is invoked
> in a different thread than any other. This forces memory safety in
> the only case I can see that does not otherwise explicity require
> it.
>
>
> Do you know of others?
>

I think RTSJ is underspecified in some areas, so it's hard to find all the places where people on this list might have concerns. I'd be happy to pass everyone's comments along, but I wonder if they'd be more effective if sent individually.

In general, RTSJ stresses correctness over performance, which is opposite from how many people on this list think. Even though it isn't mentioned in the spec, I think the RTSJ designers are depending on strongly-consistent memory.

For example: RTSJ doesn't mention that 'synchronized' transmits values between threads; visibility concerns are completely missing from RTSJ; 'synchronized' - except for mutual exclusion - is missing in the few RTSJ code samples I've seen.

Furthermore, RTSJ overloads 'synchronized' to defer asynchronous interruption, which would tend to discourage the use of 'synchronized' when it isn't needed for mutual exclusion.

Note: The half-synchronized WaitFreeQueue classes do not appear to comply with the current JMM.

--
Joe Bowbeer

------------------------------- JavaMemoryModel mailing list - http://www.cs.umd.edu/~pugh/java/memoryModel



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