Re: pthread condition vars - Doh!

[Christopher Faylor <cgf at redhat dot com>]

On Thu, Apr 19, 2001 at 10:05:55AM +1000, Robert Collins wrote:
>----- Original Message -----
>From: "Christopher Faylor" <cgf@redhat.com>
>To: <cygwin-developers@cygwin.com>
>Sent: Thursday, April 19, 2001 9:51 AM
>Subject: Re: pthread condition vars - Doh!
>
>
>> On Thu, Apr 19, 2001 at 09:46:52AM +1000, Robert Collins wrote:
>> >I've just found out that SignalObjectAndWait, which I use in several
>> >locations in the pthreads code, is not available on 9x platforms.
>> >SignalObjectAndWait is the appropriate function to prevent races for
>> >emulated posix objects that involve more than 1 win32 object.
>>
>> Yep.  I have long wanted a SingalObjectAndWait for Cygwin's signal
>> handling but I couldn't use it for this reason.  I missed that you
>> were using this in your new code.
>>
>> I assume that you'll be providing some kind of wrapper to handle
>> this?
>
>Nice try :]. Long term I hope so. Short term if(95){race}else {don't
>race}.

I just meant that you'd provide a wrapper that did something like:

signal_object_and_wait (blah)
{
  DWORD res;
  if (os_being_run == winNT)
    res = SignalObjectAndWait (blah)
  else
    {
      SetEvent (or whatever);
      res = WaitForSingleObject ();
    }

  return res;
}

>I found this out when John Fortin mailed me a link to an article on
>developing condition vars for win32. I had the same essential solution
>(barring things like hiding win32, using InterLocked calls and being
>cross process ;].  At the end of it the authors mentioned
>SignalObjectAndWait as an issue for 95. The only solution the authors
>are describing (for cond vars) seems to involve creating a new win32
>Event for each waiter, which is a huge overhead. I'm going to look into
>something like
>
>set_pri(-15)
>releasemutex
>waitforfoo
>set_pri(previous value).
>
>Which given the win32 scheduler should pretty much guarantee no races
>(particularly if the pri is above the available priority for any other
>cygwin threads), and as we are blocked, we won't deadlock. I've only
>just started thinking about this - this is really verbal rambling..

I came across a web site years ago that claimed to be able to do this
in a non-raceable fashion -- or at least I dreamed I did.  I never have been
able to find it again.

cgf