Mail Archives: cygwin-developers/2001/10/22/11:01:06
On Sun, Oct 21, 2001 at 10:18:05PM -0400, Jason Tishler wrote:
>Rob,
>
>On Mon, Oct 22, 2001 at 11:54:39AM +1000, Robert Collins wrote:
>> Of course, if python doesn't set thread priority then 3 is unlikely.
>
>I don't know, but I found the following tidbit while grep-ing the Python
>code for "priority":
>
> // Using Sleep(0) can cause a priority inversion.
> // Sleep(0) only yields the processor if there's
> // another thread of the same priority that's
> // ready to run. If a high-priority thread is
> // trying to acquire the lock, which is held by
> // a low-priority thread, then the low-priority
> // thread may never get scheduled and hence never
> // free the lock. NT attempts to avoid priority
> // inversions by temporarily boosting the priority
> // of low-priority runnable threads, but the problem
> // can still occur if there's a medium-priority
> // thread that's always runnable. If Sleep(1) is used,
> // then the thread unconditionally yields the CPU. We
> // only do this for the second and subsequent even
> // iterations, since a millisecond is a long time to wait
> // if the thread can be scheduled in again sooner
> // (~100,000 instructions).
> // Avoid priority inversion: 0, 1, 0, 1,...
>
>The above seems to resonant with your possibility #3.
Aha! Interesting. That explains why Sleep (1) seemed to work better in
some situations in cygwin than Sleep (0).
cgf
- Raw text -