Re: Non-blocking memory allocation in real time threads
Re: Non-blocking memory allocation in real time threads
- Subject: Re: Non-blocking memory allocation in real time threads
- From: Jeff Moore <email@hidden>
- Date: Tue, 9 Aug 2005 12:09:35 -0700
The best thing to do is to pre-allocate the things you need in a pool
that has non-blocking accessors. That way, the code executing on the
real time thread can do two interesting things. First, it can
"create" and "destroy" objects. Secondly, and probably more
important, it can profile your resource usage and alert your engine
to overflow/underflow conditions.
In the case of C++, there are two really good tools at your disposal.
First, when dealing with standard library constructs like vector, you
can specify your own allocator object with which the specific
instance will use. Allocators just deal in raw memory, so you can
write one that pre-allocates a block of memory and sub-allocates out
of that. Provided you control the creation/deletion of the standard
library objects, you can control the re-entrancy into your allocator.
The other great tool that C++ gives you is the ability to customize
operator new and operator delete. You can specify how these
operations work on a per-class basis. Again, you have the opportunity
to pre-allocate a block of memory and do sub-allocations out of it.
With the same care on creation/deletion, the re-entrancy is manageable.
One last thing I'll mention is malloc zones. Malloc zones allow you
to set-up a memory zone with the malloc library. Since malloc manages
it's locks on a per-zone basis, you have the capability of setting
things up so that allocations/frees on the real time thread won't
block. Note that you'll need to write your own operators new and
delete if you want to use malloc zones with the C++.
You can read more about malloc zones and other memory allocation
strategies here: http://developer.apple.com/documentation/Performance/
Conceptual/ManagingMemory/Articles/MemoryAlloc.html
On Aug 8, 2005, at 4:06 AM, Marcus Zetterquist wrote:
Hi!
I've been trying to search the archive for this with no result:
So far our Core Audio and Core MIDI real time code has been
designed never
to allocate memory from the heap.
Now we would like to use C++ new, std::vector , std::string and so
forth in
the Core Audio/MIDI callbacks. These calls will be made rarely though.
Is there a good way to make sure these calls never block? We need
to avoid
crackles in the audio caused when _another_ thread has caused this
heap's
mutex to be locked.
It would be nice, for example, to be able to create a special heap
that only
the Core Audio callback allocates memory from = this heap will
never have
its mutex locked by another thread. I realize I would have to make
my own
operator new or use STL allocators or something too.
Any pointers?
/Marcus
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Coreaudio-api mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden
--
Jeff Moore
Core Audio
Apple
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Coreaudio-api mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden