Mailing-List: contact dev-help@apr.apache.org; run by ezmlm
Precedence: bulk
Errors-To: <wrowe@rowe-clan.net>
Message-ID: <0c5801c11a10$f7106410$93c0b0d0@roweclan.net>
From: "William A. Rowe, Jr." <wrowe@rowe-clan.net>
To: "William A. Rowe, Jr." <wrowe@rowe-clan.net>,
        "Aaron Bannert" <aaron@ebuilt.com>, <dev@apr.apache.org>
References: <008901c119e7$f1071ec0$8100a8c0@godzilla>
 <20010731122140.A21458@ebuilt.com>
 <0b6101c11a02$63dab960$93c0b0d0@roweclan.net>
Subject: Re: Conditionals...
Date: Tue, 31 Jul 2001 17:34:05 -0500
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit


----- Original Message ----- 
From: "William A. Rowe, Jr." <wrowe@rowe-clan.net>
To: "Aaron Bannert" <aaron@ebuilt.com>; <dev@apr.apache.org>
Sent: Tuesday, July 31, 2001 3:50 PM
Subject: Re: Conditionals...


> From: "Aaron Bannert" <aaron@ebuilt.com>
> Sent: Tuesday, July 31, 2001 2:21 PM
> 
> 
> > I've been looking into this over the last few days and although I'm
> > totally in favor of adding condition variables to APR, I'm not yet
> > convinced that we can properly implement them on non-POSIX platforms
> > without some level of kernel support. There is one specific place where
> > I'm seeing a problem:
> > 
> > - cond_wait() takes a locked mutex that is associated with the cond.
> > - it will unlock that mutex and go to sleep
> > - when it awakens it must immediately reacquire that mutex (awaken() and
> >   acquire() must be a single atomic operation)
> > - finally, cond_wait() returns.
> > 
> > Does anyone know of a way around this without some sort of kernel support
> > to make those two operations atomic? This seems like a serious potential
> > for race/deadlocks.
> 
> Oh duh, this is a breeze on win32 [except that cond's themselves must be implemented.]
> 
> http:....

wrong href...

http://msdn.microsoft.com/library/en-us/dllproc/hh/winbase/synchro_5h2s.asp?frame=true

Only solves NT, but if we use some cheap trick on 9x to emulate, I don't much care.

Bill