This is the mail archive of the cygwin-developers@cygwin.com mailing list for the Cygwin project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]

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


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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]