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