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: <029401c0c864$94e515e0$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>
Subject: Re: pthread condition vars - Doh!
Date: Thu, 19 Apr 2001 10:05:55 +1000
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
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: 18 Apr 2001 23:59:01.0391 (UTC) FILETIME=[8A4BB9F0:01C0C863]

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

Ideally some low level win32 god will step up now and say \"if you
do "foo
and bar
then release
then wait
then foobar"
you will be non-interrupted between release and wait\"


Rob

> cgf
>