Mail Archives: cygwin-developers/2001/04/18/20:09:55
----- 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
>
- Raw text -