Mailing-List: contact cygwin-developers-help AT sourceware DOT cygnus DOT com; run by ezmlm
List-Subscribe: <mailto:cygwin-developers-subscribe AT sources DOT redhat DOT com>
List-Archive: <http://sources.redhat.com/ml/cygwin-developers/>
List-Post: <mailto:cygwin-developers AT sources DOT redhat DOT com>
List-Help: <mailto:cygwin-developers-help AT sources DOT redhat DOT com>, <http://sources.redhat.com/ml/#faqs>
Sender: cygwin-developers-owner AT sources DOT redhat DOT com
Delivered-To: mailing list cygwin-developers AT sources DOT redhat DOT com
Date: Wed, 18 Apr 2001 20:19:57 -0400
From: Christopher Faylor <cgf AT redhat DOT com>
To: cygwin-developers AT cygwin DOT com
Subject: Re: pthread condition vars - Doh!
Message-ID: <20010418201957.D6403@redhat.com>
Reply-To: cygwin-developers AT cygwin DOT com
Mail-Followup-To: cygwin-developers AT cygwin DOT com
References: <025701c0c861$e40e01c0$0200a8c0 AT lifelesswks> <20010418195107 DOT B6060 AT redhat DOT com> <029401c0c864$94e515e0$0200a8c0 AT lifelesswks>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.3.11i
In-Reply-To: <029401c0c864$94e515e0$0200a8c0@lifelesswks>; from robert.collins@itdomain.com.au on Thu, Apr 19, 2001 at 10:05:55AM +1000

On Thu, Apr 19, 2001 at 10:05:55AM +1000, Robert Collins wrote:
>----- Original Message -----
>From: "Christopher Faylor" <cgf AT redhat DOT com>
>To: <cygwin-developers AT cygwin DOT 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