httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Dean Gaudet <>
Subject RE: [PATCH] Serialize the update to pool.sub_* in destroy_pool
Date Mon, 15 Dec 1997 21:40:46 GMT
On Mon, 15 Dec 1997, Ben Hyde wrote:

>  Dean Gaudet wrote:
> > Yuck.  All accesses to foo->sub_pools, sub_next, and sub_prev need to
> > be serialized.
> I think this was the last one, the others were serialized, possibly by
> chance,
> as part of serializing the access to the block "heap."  Since that is
> already
> forcing the serializing around pool create/distroy/grow it's the real
> bottleneck,
> not that there are subpools.

In clear_pool()

    while (a->sub_pools)

would need to be serialized as well...  I think that's it.

> Yeah, there is a deep truth here, that the heap and the thread, and the
> clean up are all one very tight knot.

Yeah I think we're getting somewhere on defining the api such that we've
got lightweight unsynchronized allocations.

> > Ok I've convinced myself that we don't need to serialize the sub_pools
> > thing at all... we just need to have a few examples of how to do
> > multithreaded stuff "right".  But have I convinced anyone else?
> I'm convinced, but for the serialization around block allocation makes
> it
> all a mute point, assuming I'm not confused.

We can fix that one too, it's "behind the scenes".  We can give each
thread a pool of blocks that it can allocate from privately.  A block can
be returned to any free list i.e. blocks don't belong to a particular
thread, the freeing thread just adds it to its own free list.  We can
probably arrange this so that it gets into a "steady" state -- or maybe
have a tunable which says "a thread should keep 32 free blocks for itself,
anything beyond that should go back to the global free list". 

> I'm still yearning for a lighter weight acquire_mutex.  It's way bad to
> be
> in a cost/reliablity trade off around mutex.  Been there, done that,
> went
> to the funeral.  - ben h.

Yeah big time.  I presume that the WaitForSingleObject and ReleaseMutex
stuff are syscalls.  We can do a pretty simple bit of asm to avoid bopping
into the system unless the thread actually has to block.  There's nothing
particularly wrong with the acquire_mutex()/release_mutex() pair right? 
I've done this before under OS/2 ages ago, sped up the mutexes by more
than an order of magnitude. 

POSIX mutexes are defined so as to make fast user-land mutexes possible,
with syscalls only when you have to block the thread.


View raw message