Re: Thoughts on locks

[Brian Pane]

Justin Erenkrantz wrote:
On Tue, Jun 26, 2001 at 10:49:42AM -0700, Brian Pane wrote:
Please forgive me if this issue has been covered previously, but
I've been wondering lately about whether it would be useful to
add support for lightweight spin-locks as  a complement to the
current intraprocess locks in APR.  There are some places, like
the pool memory allocator, where a spinlock might perform better
than a pthread mutex.  Thoughts?
Well, I just about to write a message saying that we ought to remove the
mutexes from the pool memory allocator code ANYWAY. AFAICT, the pool
only needs to be locked when the pool is shared across workers - which 
only seems to be the case with the global or child pool.  Locking the
pool should be the exception, not the norm.  What Cliff just suggested
about APR_XTHREAD sounds like it could apply to the pool as well.

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

--Brian