This is the mail archive of the cygwin-developers@cygwin.com mailing list for the Cygwin project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]

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


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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]