This is the mail archive of the cygwin-patches@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]
Other format: [Raw text]

Re: [Patch] Fix gethwnd race


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...


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