httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Greg Stein <gst...@lyra.org>
Subject Re: some reasons why Apache 2.0 threaded is slower than prefork
Date Thu, 01 Mar 2001 22:23:29 GMT
On Thu, Mar 01, 2001 at 03:42:54PM -0500, Rodent of Unusual Size wrote:
> Cliff Woolley wrote:
> > It's the "lock-free operations" part that I've been stumbling over
> > so far.
> 
> OpenVMS on the VAX dealt with this by using the low bit of the
> pointer as a lock.  Blocks were always 64-bit aligned, so it
> was free.  They used interlocked instructions that were guaranteed
> atomic:  BBSSI (branch on bit set and set, interlocked) and BBCCI.
> I do not know how we could use that here, but it was simple and
> elegant.. thread, process, and SMP safe.

I once tried to created a lock-less linked-list for managing some thread
state stuff in Python. I believe that it finally came to a point where I had
a simple proof that you just can't implement a read/write linked list in a
multi-threaded environemnt without a lock. Beats me if I can remember the
key point, though.

If you can quickly recover a per-thread linked-list, then you won't need any
locks. We have per-thread data in APR, so APRUTIL can easily implement a
system based on intraprocess locks or on a per-thread basis.

Conceivably, you could also implement them on a per-pool rather than
per-thread basis. This could allow you to hook your list to the connection
pool (this would still cause some ramp-up malloc's on the first request of a
connection, though).

Cheers,
-g

-- 
Greg Stein, http://www.lyra.org/

Mime
View raw message