Hideto Ishibashi wrote:
(...)
> Actually I'm working on RT versions of the C allocation functions
> malloc()/free() and C++ operator new/new[]/delete/delete[]
> (although it'll be possibly a bit different from the ISO/ANCI
> C/C++ standard). It looks working well at non-RT debugging with gdb.
> So I think it's almost to work on RT-Linux.
>
> I think it'll be finished, at worst, by the end of the March.
> And I'm going to report when it's finished.
>
> Regards,
> Hideto
Sounds interesting... :-) In most cases dynamic allocation is not an
option in real time code, because of the risk of being delayed by
another process. But if it could be implemented without mutex, I think
it may be quite useful in complex real time systems, especially when
large ammounts of structured data has to be handled. (I'm thinking about
picking that Audiality* project up again, when I get a proper Linux box
set up at home. That's how I found ways to really make use of C++ in
real time tasks. :-)
I have been thinking about this before, but haven't coded anything, as I
haven't had any need for RT memory allocation so far. Have to keep the
old DOS based firmware alive as well... :-( But I have three ideas that
may be useful...
1) Getting the heap.
The simple solution would be to simply kmalloc() some, and add it to
the RT "memory manager" at startup. To get rid or this fixed memory
limit (in case you want to be able to balance memory usage between RT
and non-RT at run time), some kind of driver could be set up to
kmalloc()
and kfree() as needed, keeping the ammount of RT memory avaliable for
quick allocation at a specified level. There is of course, a risk of
getting a "memory not yet available" error (or blocking if prefered)
if you allocate too much memory before the driver gets a chance to get
more, but at least, you're not limited to allocating all you need in
module_init().
2) Mutex problem.
If one task is allocating while another one gets the same ides, what
will happen? I think the most logical solution would be to make sure
that the blocked task can resume ASAP after the first one has returned
from alloc.
3) Memory fragmentation
As long as no one feels like doing a real deep hack in the Linux kernel
memory management code, this is a serious issue. Allocating and freeing
blocks of random sizes quickly turns a normal freelist into garbage...
The solution used by the kernel itself; different heaps for different
block sizes, is probably a simple and efficient way to go for most
applications.
Anyway, as long as all memory that will be needed isn't allocated in
advance, it's quite obvious that memory allocation and real time does
not go very well together. Latencies depend on the non-RT Linux
kernel... But as long as there is enough memory, and the exclusion
issue is handled the right way, I think it can be quite useful, even
from whithin hard real time tasks. Think of it as a flexible extension
to circular buffers and stacks! :-)
*)Audiality is an integrated sampler/synthesizer/processor/hard disk
recorder/editor with < 1 ms latency. I coded a working engine for Win16,
realized that most existing systems are just messy and limited, begun
porting to Win32, realized that WinNT really sucks more than it seems to
do at first sight, and then started coding for Linux. A while later, I
realized that I would have to build my own hardware, since specs for
professional audio interfaces is more or less impossible to get, and
drivers are either non-real time OSS, or even worse; Windoze only.
Along with all other problems it seemed too big, and I dropped it,
waiting for M$ to die... ;-)
May The Source be with you, Hideto!
//David
--- [rtl] ---
To unsubscribe:
echo "unsubscribe rtl" | mail [EMAIL PROTECTED] OR
echo "unsubscribe rtl <Your_email>" | mail [EMAIL PROTECTED]
----
For more information on Real-Time Linux see:
http://www.rtlinux.org/~rtlinux/
