delorie.com/archives/browse.cgi   search  
Mail Archives: cygwin-developers/2001/11/01/06:30:12

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: Thu, 1 Nov 2001 06:32:33 -0500
From: Jason Tishler <jason AT tishler DOT net>
To: Robert Collins <robert DOT collins AT itdomain DOT com DOT au>
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: <20011101063233.A796@dothill.com>
Mail-Followup-To: Robert Collins <robert DOT collins AT itdomain DOT com DOT au>,
cygwin-developers AT sourceware DOT cygnus DOT com
Mime-Version: 1.0
In-Reply-To: <00d501c15fd8$711598e0$0200a8c0@lifelesswks>
User-Agent: Mutt/1.3.18i

Rob,

On Mon, Oct 29, 2001 at 04:46:14AM +1100, Robert Collins wrote:
> I've fresh out of ideas.
> 
> [snip]

Please don't interpret my sluggish response time as a lack of interest or
appreciation of your efforts.  Quite on the contrary, I was blown away
by your analysis and the obvious effort that you spent debugging this
problem on my machine.  Unfortunately, I'm maxed out due to starting a
new job and already having multiple unreasonable deadlines.  Sigh...

> BTW: in thread.cc in your cygwin source, you might like to change s = !s
> to s= (s+1) % 2; I'm not sure that !s is guaranteed to give you Sleep
> (1) :}.

I just stole the idea and code from Python itself -- I'll verify that

    s = !s

works as expected and if not, then I'll try your alternative.

> Now the python thread header seems a little buggy to me.
> 1) the lock struct member locked should be volatile. (Do you have an SMP
> system Jason?)

No, I just have a single PIII 500 MHz processor.

> 2) ..acquire_lock can exit with the lock marked as owned, but return an
> error. If the calling function assumes that an error from acquire_lock
> means it' failed to acquire the lock, the lock will get wedged, and
> python will appear to hang. (the if (error) success = 0; line is the
> culprit. It should also reset thelock->locked IMO. This is congruent
> with the symptoms I see in your case.

I will investigate this possibility as soon as I come up for air.

Thanks,
Jason

- Raw text -


  webmaster     delorie software   privacy  
  Copyright © 2019   by DJ Delorie     Updated Jul 2019