fix cond_race... was RE: src/winsup/cygwin ChangeLog thread.cc thread.h ...

Christopher Faylor cgf@redhat.com
Mon Oct 22 08:01:00 GMT 2001


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



More information about the Cygwin-developers mailing list