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