Mailing-List: contact dev-help@apr.apache.org; run by ezmlm
Precedence: bulk
Date: Tue, 26 Jun 2001 11:24:25 -0700
From: Brian Pane <bpane@pacbell.net>
Subject: Re: Thoughts on locks
To: dev@apr.apache.org
Message-id: <3B38D359.9020200@pacbell.net>
MIME-version: 1.0
Content-type: text/plain; charset=us-ascii; format=flowed
Content-transfer-encoding: 7BIT
User-Agent: Mozilla/5.0 (X11; U; Linux 2.4.2-2 i686; en-US; rv:0.9.1)
 Gecko/20010607
References: <3B38CB36.80403@pacbell.net> <20010626105930.N25512@ebuilt.com>

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