Mailing-List: contact cygwin-developers-help AT sourceware DOT cygnus DOT com; run by ezmlm List-Subscribe: List-Archive: List-Post: List-Help: , Sender: cygwin-developers-owner AT sources DOT redhat DOT com Delivered-To: mailing list cygwin-developers AT sources DOT redhat DOT com Date: Sun, 21 Oct 2001 22:18:05 -0400 From: Jason Tishler To: Robert Collins Cc: cygwin-developers AT sourceware DOT cygnus DOT com Subject: Re: fix cond_race... was RE: src/winsup/cygwin ChangeLog thread.cc thread.h ... Message-ID: <20011021221805.B1884@dothill.com> Mail-Followup-To: Robert Collins , cygwin-developers AT sourceware DOT cygnus DOT com Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <010601c15a9c$8329b070$0200a8c0@lifelesswks> User-Agent: Mutt/1.3.18i 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