Jerry Schwarz wrote:
> A is explicitly not required by Java, but as I understand it what Bill is
> proposing is something like
>
> (A') If an infinite number of "scheduling events" occur then all
> unblocked threads are guaranteed to make progress. Where a scheduling
> event is a call to Thread.yield (or Thread.sleep, ....)
That was not my interpretation of Bill's proposal. That would be far too
strong.
The current specification of Thread.yield does not require that anything
actually happen in any circumstances. It is a hint to the scheduler to
consider giving another thread an opportunity to execute instead of the
current thread. It would be valid for yield to be implemented as a no-op on
any/every system.
Similarly, there is no requirement in the JLS that while the current thread
is sleeping, some other thread gets the opportunity to execute. Though most
everyone would assume this is the case.
In both cases there is a perception of what the "programmer" would like to
have happen. For yield (and sleep) we expect that a reasonable
implementation will "do the right thing". For a user-level scheduler that
can utilise only a single CPU we expect that the scheduler will choose
another runnable thread from the ready list (perhaps taking into account
priorities and perhaps not). But when using system threads and native
schedulers a yield, or sleep, could result in a thread belonging to another
process executing.
However, the examples that Bill gave will terminate under the proposed
semantics *only* when they are the only two threads in the "system". For a
given implementation the same guarantee may be made even when other threads
are present (for example, most VM threads block when idle and are mostly
idle, so it would be reasonable to find that the two threads in the example
are the only runnable threads; or a user-level scheduler could ignore VM
threads or ....).
Consequently, the programmers expectations on the behaviour of sleep() and
yield() are not portable and can not be relied upon in any way, other than
testing a posteri that a given program does run as they expect on a given
VM. So although Bill's proposal is slightly stronger than the current
semantics for yield/sleep they do not give the programmer any assistance in
writing portable threaded applications and consequently the use of yield and
sleep still produce non portable programs (except where replacing them with
a no-op gives valid results).
Given that these stronger semantics do not actually aid the programmer in
any way I am unclear on why they have been proposed.
David Holmes
-------------------------------
JavaMemoryModel mailing list - http://www.cs.umd.edu/~pugh/java/memoryModel
This archive was generated by hypermail 2b29 : Thu Oct 13 2005 - 07:00:37 EDT