Re: Problems with dynamic allocation in tasks

[Robert A Duff <bobduff@shell01.TheWorld.com>]

ldb <ldb_nospam@hotmail.com> writes:

> I'm at a loss for how this possible using storage pools.

You're right -- it's not as simple as I implied.

> I've worked a good deal with storage pools but perhaps my vision of
> their functionality is too narrow. It was my belief that a storage
> pool can only be used globally for a particular type.

Correct.

The Allocate routine for your pool would have to grab a pointer to the
"real" pool out of thread-local storage, and allocate memory from that.
Whether thread-local storage is efficient enough depends on the
system.

I don't think there's any portable and efficient way to use thread-local
storage -- you'd have to program that.  Task_Attributes doesn't count --
it does locking, which is what you're trying to avoid.

>...These dynamic
> allocations are done with global types, ie, Access_Vector. Certainly a
> storage pool can be attached to Access_Vector and intercept, figure
> out which thread its in.. but then what? In a "simple" implementation,
> I'm still depending on System.Memory (which is malloc()) and it's
> still gonna hit these mutexes.
>
> I -could- make the storage-pool implement a full allocator so it's not
> dependant on malloc() for each allocation.

Well, yeah, if you implement your own storage pool, you have to
implement it.  ;-)

>...This is alot of work and
> there are alot of types.

Yes, it's a lot of work.  Not sure what you mean by "a lot of types".
Many types can share the same pool, if you program the pool to work
for multiple sizes and alignments.  You have to write
"for T'Storage_Pool use ..." on each type, though.

>...If I go this route, I'd prefer to do a global
> replace (which goes back to my original question of how to do it like
> gmem does it).

- Bob