apr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ian Holsman <i...@cnet.com>
Subject Re: Thoughts on locks
Date Tue, 26 Jun 2001 19:42:31 GMT
On 26 Jun 2001 12:25:44 -0700, Brian Pane wrote:
> Justin Erenkrantz wrote:
> >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.
> >
> In the current apr_palloc, the lock is only around the call to new_block.
> I think that's reasonable; new_block is manipulating a global free list, so
> it has to be mutex-protected.
> For now, I'll hack together a spin lock prototype to see if it yields any
> measurable improvement in httpd speed.
> --Brian

Isn't this simillar to the work being done with SMS and the SMS
allocater and the SMS trivial thing mentioned a while ago?

if we can removed the 'global/process' free list and changed that to
a 'thread' free list wouldn't this remove the need for mutexes?


View raw message