I think the underlying tension here is that many designs/algorithms
that somehow rely on volatiles or spinning will work in the desired
fashion only on platforms that maintain a minimal level of ("weak" or
probablistic) fairness. Some of these designs/algorithms are
sometimes more efficient than alternatives (on these platforms), so
people want to be able to use them.
Which means that they will not portably have the desired effects.
Synch-hoisting might accentuate these problems.
As David Holmes mentioned, simply giving Thread.yield a real semantics
might suffice to make such code more portable, if all such spinloops
contained Thread.yield.
Digressing: the semantics need not even be very strong. Yield could
still be ignored entirely on adequately-fair JVMs.
While changing scheduling semantics of Thread.yield probably fall
outside JSR-133, it might be worth thinking about memory rules to
associate with it that would improve portability.
-- Doug Lea, Computer Science Department, SUNY Oswego, Oswego, NY 13126 USA dl@cs.oswego.edu 315-312-2688 FAX:315-312-5424 http://gee.cs.oswego.edu/ ------------------------------- 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