> - Curently fixed at 4 pools with a fixed thread -> pool mapping. > - All pools are always initialized, even for single threaded programs, > where > only one pool is used. > - Especially realloc gets quite a bit uglier. > - I'm pondering storing the thread -> pool mapping in the thread > struct instead of computing it each time from the tcb address.
If you wanted to get rid of the static mapping of threads to pools, it would make sense to replace the per-pool region tables with a global, 2- tier table. The first tier would be a table of mutexes paired with the current style region tables, and it would pick the right one using a secondary hash. It could be much larger than the number of pools to avoid it being a bottleneck. This would eliminate the free / realloc loops. I don't think it would make sense right now, since it would add an extra pair of lock / unlock calls to each malloc / free call in the common case where allocations are freed by the allocating thread. If the thread -> pool assignment was dynamic, it would be faster due to not needing those loops. So if you wanted to do something like picking a random pool each time, this would make a lot of sense. It would be increasingly better with a larger number of pools.
