[prev in list] [next in list] [prev in thread] [next in thread] 

List:       apr-dev
Subject:    Re: Conditionals...
From:       "William A. Rowe, Jr." <wrowe () rowe-clan ! net>
Date:       2001-07-31 22:34:05
[Download RAW message or body]


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

[prev in list] [next in list] [prev in thread] [next in thread]