> Didier Kryn <kryn@???> writes:
>> Le 01/02/2016 17:52, Rainer Weikusat a écrit :
>>> there's a known upper bound for the maximum number of objects which will
>>> be needed
>>      Some applications need to asynchronously create and destroy large
>> numbers of objects while the total number of objects at any given time
>> remains bounded. Creating them in one function or in one thread while
>> deleting them in another can be a sensible way to organize the program
>> if allocation/deallocation is efficient.
> Aha ... and what is this now supposed to communicate? It looks like a
> couple of unrelated statements to me which also don't seem to have any
> relation to the idea to use an array as 'backing store' for memory
> allocation, as opposed to, say, something which allocates page (frames)
> via OS calls, eg, mmap, and divides these as required or even just a
> 'large' memory block acquired via malloc.

     Rainer, I dont understand what you don't understand :-) But I have 
the example of a Data aquisition program, where a "producer" task reads 
blocks of data from digitizers and passes them to a "consumer" task 
which sends them over the network.

     The producer allocates the blocks of data inside an mmapped kernel 
buffer and the consumer frees them after use. The allocator manages the 
kernel buffer as a backing store (called a "pool" in Ada). The kernel 
buffer is necessary because the digitizer's data is transfered by DMA, 
therefore at a known physical address, on request by the producer. It is 
mmapped to allow access from user space.

     This organization makes sense everytime there is something like a 
producer and a consumer. There's no point in allocating an unlimited 
memory size, because if the producer runs faster than the consumer it's 
quickly going to request all system memory.

     Didier