Le 01/02/2016 22:38, Rainer Weikusat a écrit :
Didier Kryn <[email protected]> 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
_______________________________________________
Dng mailing list
[email protected]
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
