At 10:37 AM 1/2/2002, Boehm, Hans wrote:
> > From: Jerry Schwarz [mailto:jschwarz@us.oracle.com]
> > >Example 1:
> > >Initially, volatile x = 0
> > >
> > >Thread 1:
> > >while (x == 0) {
> > > Thread.yield();
> > > }
> > >
> > >Thread 2:
> > >x = 1
> >
> >
> > No I do not. Unless you impose some fairness requirement, there is no
> > reason to believe that Thread 2 will ever run. I think the
> > specification of
> > yield requires that some other thread besides thread 1 will
> > make progress,
> > although even that is unclear. But unless the above are the
> > only threads
> > in the system there is no guarantee that thread 2 will run.
> >
> > Thread.yield is essentially a nop. In practical systems it is
> > important,
> > but from the point of view of the semantics of the Java it is a nop.
> >
>I agree with Jerry on this one. But I do think that if you replace Thread 1
>by
>
>int i;
>while (x == 0) {
> Thread.sleep(++i);
> }
>
>The result should terminate. Jerry, do you agree?
Yes, as a pragmatic issue (and assuming the two threads are the only
unblocked threads in the program). But giving semantics to sleep is even
trickier than giving semantics to yield.
Let me clarify my position.
I believe fairness is a highly desirable property of a thready programming
language. Its simplest form is:
(A) Any unblocked thread is guaranteed to make progress.
A slight stronger form is
(B) Any thread which becomes unblocked an infinite number of times is
guaranteed to make progress
As was pointed out earlier in this thread, such requirements are untestable
unless they are accompanied by some quantitative indication of how long it
will take for the guarantees to be effective. But in practice they are
testable and the theory is tractable.
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, ....)
My positions is that some of the considerations that led Gosling (or
whoever did it) to reject A lead to a rejection of A'. Primarily that we
don't want to impose requirements on the scheduler that might be
inappropriate in particular (currently unknown) environments. I realize
that stronger arguments can be made against A than against A', but I think
the ones against A' are still persuasive.
And I think that the semantics of Thread.yield, Thread.sleep .... are not
part of the basic Java execution model, but are library issues.
>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:37 EDT