> From: Miles Sabin [mailto:msabin@interx.com]
>
> Hans Boehm, Hans wrote,
> > 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?
>
> If longs were unbounded I would agreed. But they aren't, so any
> guarantee here can be no stronger than that for,
>
> Thread.sleep(Long.MAX_VALUE)
>
> But from the point of view of the semantics this should surely be
> the same as the guarantee (or lack of it) for Thread.sleep(n) for
> any arbitrary long n >= 0. If it isn't, then what's the greatest n
> such that the guarantee no longer holds?
>
I disagree that it should be the same for arbitrary n. In some
implementations Thread.sleep(<very small>) may just spin. (This at least
used to be the case for Linux nanosleep, and thus probably for some Linux
JVMs. It's actually somewhat defensible when you consider that the actual
granularity for really sleeping in the kernel is/was usually 10msecs.)
I would just specify that there has to be a (system- and context-dependent)
n such that the other thread will be scheduled when I repeatedly execute
sleep(n). That formulation also has the advantage that it scales and
doesn't depend on priorities: If I add another 1000 pairs of threads, with
each pair waiting on and setting a different shared variable, I'm still
guaranteed that all of them will terminate, no matter what their priorities
are. If they all did a Thread.sleep(1), the context switch time might still
be long enough that I never get around to scheduling any of the threads that
set the shared variables.
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