This is the mail archive of the
cygwin-developers@cygwin.com
mailing list for the Cygwin project.
Re: fix cond_race... was RE: src/winsup/cygwin ChangeLog thread.cc thread.h ...
- To: 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 ...
- From: Jason Tishler <jason at tishler dot net>
- Date: Thu, 1 Nov 2001 06:32:33 -0500
- Cc: cygwin-developers at sourceware dot cygnus dot com
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