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

Robert Collins robert.collins@itdomain.com.au
Sun Oct 21 19:44:00 GMT 2001


right, then try sleep (1) where I have 0 :}

> -----Original Message-----
> From: Jason Tishler [ mailto:jason@tishler.net ]
> Sent: Monday, October 22, 2001 12:18 PM
> To: Robert Collins
> Cc: cygwin-developers@sourceware.cygnus.com
> Subject: Re: fix cond_race... was RE: src/winsup/cygwin ChangeLog
> thread.cc thread.h ...
> 
> 
> 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.
> 
> Jason
> 



More information about the Cygwin-developers mailing list