Hans is correct. You must take type safety issues into account.
At 01:51 PM 7/28/2003, Boehm, Hans wrote:
> > -----Original Message-----
> > From: Bill Pugh [mailto:pugh@cs.umd.edu]
> > 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
>access to.
>
>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.
>
>Hans
-------------------------------
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