Re: Problems with dynamic allocation in tasks

["Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de>]

On Wed, 25 Jul 2007 10:04:48 -0700, ldb wrote:

> On Jul 25, 12:45 pm, Robert A Duff <bobd...@shell01.TheWorld.com>
> wrote:
>> ldb <ldb_nos...@hotmail.com> writes:

>>>...Ideally, i'd be able to
>>> create a task-local memory pool that doesn't require a mutex for these
>>> allocations.. not sure how feasible this is in Ada, though.
>>
>> It's quite feasible.  Look up storage pools (section 13.11 in the RM).
> 
> I'm at a loss for how this possible using storage pools.
> 
> 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.

In which sense? If you are going to make your pools task-local, then you
should know in advance which objects are local to the task. Types of the
objects are irrelevant, only access types count. So you just have to use
task-local access types. This will warranty that nothing would leak out:

task body Foo is
   Local_Pool : My_Own_Pool; -- The pool of the task

   type Thing_Ptr is access Thing; -- The access type of
   for Thing_Ptr'Storage_Pool use Local_Pool;

begin
   ...
   -- Now each new targeting a Thing_Ptr will go to My_Own_Pool

> I -could- make the storage-pool implement a full allocator so it's not
> dependant on malloc() for each allocation. This is alot of work and
> there are alot of types.

You have to implement only Allocate and Deallocate. Choose any of numerous
algorithms existing around. You should certainly know about the behavior of
your program. For example if you don't need to free objects, then you have
an "area", etc.

> 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).

That would be a bad idea, because in that case if you occasionally mixed
allocators / deallocators from different tasks, you'd mess up the pool
state beyond repair. It would be damn difficult to catch such bugs. With
task-local access types you are safe. Note that pool is an object, so you
can reuse your pool type implementation across many tasks just creating an
instance of for each.

P.S. If your objects aren't task-local, you could still avoid mutexes on a
single-CPU machine by implementing your pool owned by a protected object
with priority ceiling locking (ARM D.3)

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de