On Sun, Jul 08, 2001 at 10:19:33AM -0700, Justin Erenkrantz wrote: > On Sun, Jul 08, 2001 at 10:14:16AM -0700, dean gaudet wrote: > > an ideal situation for free-lists (blocks of freed, but not free()d > > memory) is one per cpu. > > > > a less ideal situation is one per thread. > > > > an even less ideal situation is one per process (which requires locking). > > > > it's insane to have one per pool :) > > I think we're shooting for #2 (less ideal). Unless someone can come up > with a way to dynamically tell how many CPUs we are running on and bind > a free-list to a specific CPU. > > We're currently doing #3 (even less ideal) in apr_pools.c. > > And, yeah, the current trivial SMS is doing #4. =) But, don't expect it > to stay like that. And, if we implement the apr_sms_child_malloc, it > gets to somewhere between #2 and #3. -- justin
#5 the approach taken by tdb. have a hash-chain. then you get the best of all worlds. simultaneous access only requires that you lock *one* hash chain, which allows a theoretical limit of number-of-hash-bucket simultaneous accesses. luke p.s. i'm hoping that people will not be put off by tdb's GPL license because i think that there are some really good techniques used in there that could be applied to APR code, too.
