>>
>
>But your original informal statement is much stronger. It is
>imposing requirements on Thread.yield not on the compiler. Imposing
>requirements on Thread.yield is something I continue to object to.
>
>It seems that this restatement in terms of compiler transformations
>is approximately: when a thread does a yield it can't be holding
>more locks than the plain semantics would allow. That is something I
>don't object to.
In general, I think it is a horrible idea to define semantics in
terms of allowed compiler transformations. The problem is that you
never know when some combination of other compiler transformation
might cause the same bad behavior as the banned compiler
transformation, or when you might be forbidding a transformation
needlessly. For example, would it be legal to transform a program so
that a yield was holding more thread-local locks than originally? I
believe it should be legal.
Instead, we should define the semantics in terms of the allowed
behaviors of programs.
Plus your suggestion doesn't address yielding loops with volatile
variables. Do you think the following code should be guaranteed to
terminate?
Example 1:
Initially, volatile x = 0
Thread 1:
while (x == 0) {
Thread.yield();
}
Thread 2:
x = 1
Also, please note that I'm not suggesting that yield or sleep have
any visibility semantics. Performing a yield/sleep does not mean you
have to flush/reload variables from registers or the cache.
Bill
-------------------------------
JavaMemoryModel mailing list - http://www.cs.umd.edu/~pugh/java/memoryModel
This archive was generated by hypermail 2b29 : Thu Oct 13 2005 - 07:00:36 EDT