Josh Bloch writes:
> Sorry, I haven't been following the latest [yield] discussion in any
detail ..
Here is the context:
Bill Pugh writes:
> ... thread 1 could spin forever without giving thread 2 a chance
> to set Volatile2 to 1
David Holmes writes:
> Which is why, when doing a busy-wait, you should use
> Thread.yield (even though that is not *guaranteed* to be
> effective we will one day fix the JLS to make it so - I hope).
Doug Lea writes:
> 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.
Bill Pugh writes:
> I agree that it would be nice to think about what such changes
> might be, even if we don't make them part of this JSR.
>
> For example,
>
> Thread.yield() allows all other threads of equal or higher
> priority a chance to make progress.
----- Original Message -----
From: "Joshua Bloch" <joshua.bloch@sun.com>
To: <javamemorymodel@cs.umd.edu>; "Bill Pugh" <pugh@cs.umd.edu>
Sent: Tuesday, October 23, 2001 9:34 AM
Subject: Re: JavaMemoryModel: Fairness Guarantees in the Memory Model?
Folks,
> Thread.yield() allows all other threads of equal or higher
>priority a chance to make progress.
Sorry, I haven't been following the latest discussion in any detail, but
it
might be worth adding a note. Around here, it has long been held that a
legal,
if unhelpful, implementation of Thread.yield is a no-op.
Regards,
Josh
-------------------------------
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