[Patch] Fix gethwnd race
Brian Ford
ford@vss.fsi.com
Fri May 14 15:59:00 GMT 2004
On Fri, 14 May 2004, Christopher Faylor wrote:
> If you had said: "I was trying to avoid having a persisent muto for what
> is basically a one-time use" that would have made a lot more sense to me.
I thought you knew it was a one time event, and my reasoning was more:
"I was trying to avoid having a persistent muto since we need another
synchronization event anyway."
Obviously, I floundered in my communication. Sorry, but I am *trying* to
be clear. Email is not always my best medium.
> What you said was: "I can't use a muto because a muto would have to be
> acquired and released by the same thread".
Together with the above: "I can't use a muto as the *only* synchronization
object because..."
> There is nothing in this message that I can see which supports this claim.
I'm sure I missed the point here. Obviously, the muto code supports that
claim muto::release:
if (tid != this_tid || !visits)
{
SetLastError (ERROR_NOT_OWNER); /* Didn't have the lock. */
return 0; /* failed. */
}
> When someone makes a claim like this, I immediately think that they do not
> understand the actual problem and, so, do not devote a lot of time into
> looking at any proposed solution.
>
> I'm sure you understand this since you frequently say that you have
> little time to work on cygwin. Given that nearly everyone who donates
> time to work on free software is similarly constrained, it should not
> be surprising that eventually we develop short cuts for making sure that
> any time we spend is spent effectively.
I haven't found any good short cuts yet. I hope I do soon. That would
give me more time to work on Cygwin :-). My perfectionist nature really
gets in the way here.
> Looking for little clues of "not getting it" is usually a good way of
> figuring out how much time to spend on an issue.
That's fair if you give the person a chance to explain.
> I can see the merits in trying to avoid an additional handle but I don't
> think inventing a mutex-like structure just for use in windows.cc merits
> that much effort.
Unfortunately, I did give it way too much effort, but this "structure"
is used in many other places.
What we really need is a broadcast condition variable.
> It's difficult for me, looking at your code, to verify that you have
> achieved thread safety. It's a lot easier for me, writing standard
> code, with a standard cygwin control structure, to verify thread safety.
Mostly agreed, but the interlocked increment/decrement part is pseudo
standard Cygwin control structure.
> However, I'll look at your code again with my new understanding of your
> intent.
No need. Just before falling a sleep last night, I remembered a case I
had not covered correctly. If the initialization fails the first time,
the event is not reset. Can this just be a fatal condition? That would
sure make things simpler. I don't think any calling code is prepared to
deal with that failure anyway.
I'll cook up a muto based solution in the next few minutes now
that I understand your preference. But, I'd like an opinion on the
question above.
Thanks for being gentle with me.
--
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