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. -aaron On Tue, Jul 31, 2001 at 06:39:57PM +0100, David Reid wrote: > Folks, > > The httpd guys have started adding the code that uses pthread conditionals, > but we did talk about possibly adding it to APR. So, what do we think? > > I guess what we're talking about is > > apr_cond_t > > apr_cond_create > > apr_cond_signal > apr_cond_broadcast > apr_cond_wait > > apr_cond_destroy > > I know it'll be a PITA to write the implementation on beos, but it *should* > be possible. Given that the code in httpd currently is unix specific > anyway, should we add a cond directory and simply return APR_ENOTIMPL for > the other platforms while work is started for them? ISTR that no clear > answer was given as to the possibility of having conditionals on OS/2, > Windows and Netware... > > david
