www.delorie.com/archives/browse.cgi   search  
Mail Archives: cygwin-developers/2001/04/18/20:22:23

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
Message-ID: <02c501c0c866$cd0c03f0$0200a8c0@lifelesswks>
From: "Robert Collins" <robert DOT collins AT itdomain DOT com DOT au>
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> <20010418201957 DOT D6403 AT redhat DOT com>
Subject: Re: pthread condition vars - Doh!
Date: Thu, 19 Apr 2001 10:22:20 +1000
MIME-Version: 1.0
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.50.4133.2400
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400
X-OriginalArrivalTime: 19 Apr 2001 00:14:51.0938 (UTC) FILETIME=[C0DDB020:01C0C865]

----- Original Message -----
From: "Christopher Faylor" <cgf AT redhat DOT com>
To: <cygwin-developers AT cygwin DOT com>
Sent: Thursday, April 19, 2001 10:19 AM
Subject: Re: pthread condition vars - Doh!


> 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;
> }

Yeah, long term. I'm not going to create such a wrapper until the
problems solved for at least 2 different object combinations. Then I'll
look for common elements and see what arises.

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

I'm happy to contribute money for hypnosis :]

Rob

> cgf
>

- Raw text -


  webmaster     delorie software   privacy  
  Copyright © 2019   by DJ Delorie     Updated Jul 2019