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.
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
This archive was generated by hypermail 2b29 : Thu Oct 13 2005 - 07:00:35 EDT