apr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "William A. Rowe, Jr." <wr...@rowe-clan.net>
Subject Re: Conditionals...
Date Tue, 31 Jul 2001 20:39:51 GMT
My response below... Brad, what does Netware look like on this?

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.

First, for Win32 syncronization objects, see this chapter


Second, it _has_ been done on Win32, as redhat's win32 pthreads (lgpl) library shows.

What exactly are we trying to accomplish?  For this to be truly useful, it has to
be abstracted to our non-pthread unix models as well :(

If we are just concerned with atomic updates, then we could implement something quite
a bit simpler...


...but if we are convinced we want to sleep on the variable, then perhaps we can use
the APC Queue to schedule the wakeable async test.


I guess I need a pointer to what it is we care to accomplish.  It can be done, but
to what end?


> 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

View raw message