Boost logo

Boost :

From: Kim Barrett (kab_at_[hidden])
Date: 2006-02-12 14:26:03


At 1:57 PM +0100 2/12/06, Pavel Vozenilek wrote:
>"David Abrahams" wrote:
>
>> [BTW, I'm not sure that avoiding dynamic allocation is an appropriate
>> goal for Shmem -- not that it matters, since I'm not suggesting you
>> build dynamic allocation into your library.]
>>
>Many of strong/weak real-time systems forbid to use
>dynamic allocation.
>
>One of shmem targets are real-time systems.
>
>/Pavel

The shmem library fundamentally provides two facilities:

1. a portable interface to a collection of related IPC mechanisms
(shared memory and memory mapped files, shared synchronization objects),

2. object allocation from a specific block of memory.

In my experience, systems which forbid all use of dynamic allocation
wouldn't touch processes with the proverbial ten foot pole, making
the shmem IPC mechanisms largely moot for them.

The object allocation mechanisms provided by shmem are, surprise,
dynamic allocation. If a system design forbids dynamic allocation,
there is nothing magical about the shmem library's allocation
mechanisms that would make it more acceptable in such a system.

So I don't find this argument convincing, speaking as someone who
does a lot of soft/hard real-time programming for a living, and is
actively using the shmem library.


Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk