apr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Justin Erenkrantz <jerenkra...@ebuilt.com>
Subject Re: Thoughts on locks
Date Tue, 26 Jun 2001 18:57:40 GMT
On Tue, Jun 26, 2001 at 11:24:25AM -0700, Brian Pane wrote:
> I'm all in favor of getting rid of the mutexes in the pool allocator code
> where possible.  I think locking is inevitable, though, in order to handle
> the allocation of new blocks for a pool--which seems to be where most
> of the mutex lock/unlock behavior in the httpd is currently.  That's where
> it would be nice to have a more lightweight alternative to a pthread mutex.

Right, but most of the pools are pools for request (request_rec->pool).
By definition, they can only live in one worker (thread, process, etc.),
so there is no possibility of contention.  We're spending time locking 
code that has no business being locked.

Now, I could be misunderstanding this, but I doubt that we need to lock
the pools in this case.

> >As far as spinlocks go, can these be done in a crossplatform way?  The
> >issue is that we need an atomic operation to do the spinlock in.
> >
> I think the implementation would have to be a set of N+1 
> architecture-specific
> ifdef blocks: N containing the inline assembly directives for N supported
> processors, and one containing a pthread mutex based fallback 
> implementation.

If you volunteer to write the code and maintain it, go for it.  It will
be awful to maintain though.  But, in this particular case, I think we 
can just remove the locking entirely.  Maybe add a APR_NATIVE mutex
method for apr_create_lock_np() (Jeff's new function)?  -- justin


Mime
View raw message