[Patch] Fix gethwnd race

Brian Ford ford@vss.fsi.com
Thu May 13 20:28:00 GMT 2004

On Thu, 13 May 2004, Christopher Faylor wrote:

> >I can't seem to make a muto fit this situation cleanly since it would
> >have to be acquired and released by the same thread.
> Why would it be acquired and released from the same thread?

What I was trying to say is that a muto must be acquired and released from
the same thread.  But here, we want to block all threads calling gethwnd
until the window thread has initialized.

> Isn't the problem that multiple people are calling gethwnd?

Concurrently, before ourhwnd has been initialized, yes.

> You even mention this in the ChangeLog below.  Given that, the place to
> put a mutex would seem to be in gethwnd.

It seems to me that you would still need the window_started event then,
no?  Since a muto contains an event, why use two?  I thought this was
lighter weight.

> So, I'm not sure this patch is the right way to go.  Sorry!
> I have a patch ready.  I was waiting to see if you had something ready
> by the end of the day but, unfortunately, I don't think your patch is
> moving in the right direction.

I'm not sure why since you didn't voice a very compelling objection, but I
don't really care that much.  I was just trying to help out.

I'd like a chance to comment on your version, though.

> Do you have a simple test case which tickles the problem, by any chance?

I'm just using the original one presented here:


> I'd like to see if what I've done actually solves anything.

Me too ;-).

Brian Ford
Senior Realtime Software Engineer
VITAL - Visual Simulation Systems
FlightSafety International
the best safety device in any aircraft is a well-trained pilot...

More information about the Cygwin-patches mailing list