22 Jan
2010
22 Jan
'10
4:44 p.m.
On January 21, 2010 09:28:19 am torbenh wrote:
> I assume std::priority_queue can't be used,
because it uses a
> std::vector which will, under the covers, allocate memory from the
> stack.
You mean the heap?
you can specify an Allocator for most STL containers.
but i am not aware of anybody using them with an RT safe allocator.
might be possible.
but the allocator is not the problem.
its lockfree access.
> It would be interesting to try to write an STL queue-like container
> with an allocator that grabbed chunks of memory from a pool in an
> RT-safe way. Maybe via message-passing over a ringbuffer? Anyone
> seen/have such a thing?
MusE-1 does this.
See muse/memory.cpp and muse/memory.h, and the usage of it
for allocating play and record events in muse/mpevent.h
Ultimately it just uses 'new' for the actual allocation.
MusE-2 does not custom allocate, but like MusE-1 still uses
inter-thread messaging. You might find some good ideas in both.
We have this in MusE-2's equivalent, it appears to just use default alloc
rather than the commented out attempt:
// typedef std::multiset<MidiEvent, std::less<MidiEvent>,
// __gnu_cxx::__mt_alloc<MidiEvent> > MPEL;
class MidiEventList : public std::multiset<MidiEvent, std::less<MidiEvent> >
I think it's because in MusE-2, being a Jack midi app, audio event lists
(used by audio thread) and midi event lists (used by midi thread)
were unified.
In MusE-1, an ALSA midi app, for the audio and midi threads the two lists
are separate, requiring custom alloc.
What about instead of alloc, would this be of use to you (us)?
In SGI's help Allocators.html:
"pthread_alloc A thread-safe allocator that uses a different memory pool for
each thread "
Tim.
dunno... i never looked at implementing an allocator.
shouldnt be that hard.
but as stated, this is still a trivial part of the problem.