Mailing-List: contact cygwin-developers-help AT sourceware DOT cygnus DOT com; run by ezmlm
List-Subscribe: <mailto:cygwin-developers-subscribe AT sources DOT redhat DOT com>
List-Archive: <http://sources.redhat.com/ml/cygwin-developers/>
List-Post: <mailto:cygwin-developers AT sources DOT redhat DOT com>
List-Help: <mailto:cygwin-developers-help AT sources DOT redhat DOT com>, <http://sources.redhat.com/ml/#faqs>
Sender: cygwin-developers-owner AT sources DOT redhat DOT com
Delivered-To: mailing list cygwin-developers AT sources DOT redhat DOT com
Date: Mon, 22 Oct 2001 11:01:57 -0400
From: Christopher Faylor <cgf AT redhat DOT com>
To: cygwin-developers AT cygwin DOT com
Cc: Robert Collins <robert DOT collins AT itdomain DOT com DOT au>
Subject: Re: fix cond_race... was RE: src/winsup/cygwin ChangeLog thread.cc thread.h ...
Message-ID: <20011022110157.A7609@redhat.com>
Reply-To: cygwin-developers AT cygwin DOT com
Mail-Followup-To: cygwin-developers AT cygwin DOT com,
	Robert Collins <robert DOT collins AT itdomain DOT com DOT au>
References: <010601c15a9c$8329b070$0200a8c0 AT lifelesswks> <20011021221805 DOT B1884 AT dothill DOT com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20011021221805.B1884@dothill.com>
User-Agent: Mutt/1.3.21i

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