At 12:10 PM 09/25/2001, Boehm, Hans wrote:
>Jerry wrote:
> > Put another way, the semantics of code is defined by the
> > possible sequences
> > of memory actions it might perform in the presence of
> > unknown, but possible
> > threads. A thread is possible if it executes code from the
> > program. For
> > example, if no code sets x to a negative value, then the
> > transformation can
> > assume that x is non-negative.
> >
>I actually worry about this sort of definition, if it effectively prevents
>the compiler from taking advantage of certain true information about program
>execution. For example, the fact that a particular object is only accessed
>by one thread in the program seems to be potentially very useful
>information. If the compiler can correctly deduce such things, it should be
>able to use them.
The way I think about transformations that depend on what threads might
exist is that they occur at a higher level. That is they replace the
definition of the code that is running in the thread by some other code
that isn't generally equivalent, but is equivalent in the context.
The simplest case I can imagine is that if somehow you know that the
program will only run in one thread then you can suppress all memory
operations, even those associated with volatiles. But the right way to
deal with this isn't to have semantics that allow for the elimination of
memory operations but rather to say that in some circumstances you can
replace code that has one "semantics" by code that has a different semantics.
>Does it suffice if we aim for allowing transformations that remain valid if
>some subset of the threads is replaced by their sequentially consistent
>version? At least that seems to preclude Bill Pugh's most recent example.
>And it's at least not obvious to me that that route requires talking about
>control-dependence or really restricts analysis. (It's also not obvious to
>me whether or not it might lead to a real specification.)
>
>Hans
>-------------------------------
>JavaMemoryModel mailing list - http://www.cs.umd.edu/~pugh/java/memoryModel
-------------------------------
JavaMemoryModel mailing list - http://www.cs.umd.edu/~pugh/java/memoryModel
This archive was generated by hypermail 2b29 : Thu Oct 13 2005 - 07:00:35 EDT