> -----Original Message-----
> From: Bill Pugh [mailto:email@example.com]
> At 10:11 AM -0700 7/28/03, Jerry Schwarz wrote:
> >Put another way. If the code doesn't contain any threading
> >constructs (volatile, synchronize, ...) then the compiler shouldn't
> >be forced to treat the code is if it will be running in a
> >multithreaded context.
> I've been thinking about this for several years actually. I think the
> only limitation on compilers in synchronization-free code is that
> they may not introduce additional reads or writes of shared variables
> if the additional reads/writes could be detected. It turns out that
> you can introduce additional writes if you know that all of the
> writes will write the same value, because this can't be detected.
It seems to me that Jerry's view is very reasonable for C/C++, but I don't see how
to make it work for Java.
If we start out with (using C notation):
j = p -> f;
A C compiler may conceivably compile this as:
p = &(p -> f);
j = *p;
In Java that clearly violates type safety if p is in shared memory; an observer thread
may use the intermediate value of p to access parts of memory it shouldn't have
You could still allow this for non-reference fields in Java. But there is a strong
argument that would also be removing guarantees from the existing spec, and it would
almost certainly break security for some existing code. And the spec would now
have to treat the two cases separately.
JavaMemoryModel mailing list - http://www.cs.umd.edu/~pugh/java/memoryModel
This archive was generated by hypermail 2b29 : Thu Oct 13 2005 - 07:00:47 EDT