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
