I found a way around what I thought were the problems. It isn't really
a per-thread pool, but a per-thread cache that sits in front a ordinary
pool. The cache allocates hunks from the pool, doles them out as
objects, and caches released blocks for re-use. When the released
blocks reach a threshold, the stuff gets dumped back into the pool. The
idea came from Google's memory manager.

The allocation and release calls still go to the pool. The pool keeps
per-thread caches in thread specific data, and passes the calls to the
thread cache. Thread specific data is a little expensive on IA32
platforms, but AMD64 platforms can dedicate a register to thread
specific data, make it quite cheap.

The problem I had with per-thread pools is that unless you can guarantee
that an object created by a thread is also released by -- and only by --
that thread, it still needs to be interlocked.

And speaking of threads, although it isn't particularly advertised, gcc
has added compiler intrinsics for interlocked add, subtract, and compare
and swap (among other). Google __sync_add_and_fetch for details.


Claudio Valderrama C. wrote:

>> -----Original Message-----
>> From: Firebird-Architect@yahoogroups.com
>> [mailto:Firebird-Architect@yahoogroups.com] On Behalf Of Jim Starkey
>> Sent: Viernes, 23 de Abril de 2010 11:01
>>
>> Memory pools are very useful to avoid fragmentation when managing
>> objects of radically different lifetimes. The Vulcan pool
>> manager came
>> from Netfrastructure. In continued to evolve in Falcon and now
>> NimbusDB. It now uses an AVL tree to manage large free
>> objects and has
>> per-thread memory cache that is a *huge* win, making memory
>> allocations
>> almost free.
>>
>
> I'm glad to see that you are able to change your opinions. Three years ago,
> you rejected Alexander Peshkoff's idea of thread-specific memory pools in
> Firebird, saying it was nonsense because it didn't allow recombination of
> freed memory fragments.
>
> C.
>
>
>
>
> ------------------------------------
>
> Yahoo! Groups Links
>
>
>
>
>

--
Jim Starkey
NimbusDB, Inc.
978 526-1376



[Non-text portions of this message have been removed]