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. > >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. If you volunteer to write the code and maintain it, go for it. It will be awful to maintain though. But, in this particular case, I think we can just remove the locking entirely. Maybe add a APR_NATIVE mutex method for apr_create_lock_np() (Jeff's new function)? -- justin
