Ken.
Please don't think that I was advocating the abandonment of all
thoughts of creating a "real-time memory allocator" under all possible
sets of conditions -- No. What I was arguing was that it's
"impossible" in general, that there is no "one-size-fits-all". Many
problems have finite limitations which can provide practical limits to
what is otherwise an open-ended black-hole. If you know from the
design of your program that either
a) the total memory requirements are finite
or
b) the memory requirements per unit time is finite
then it's eminently practical to construct a memory-dispensing
allocator. I've done a few and, given the constraints of finite (and
small finite) requirements, they work "perfectly". I've never done
one that's designed to work within the rt-environment but I can almost
see my way there off the top of my head [seeing my way and actually
traversing the distance are two different things. Hey, I can see the
way to the moon ... Well, you know what I mean].
The only "gotcha" I can see in the RT-environment is that
pre-emption can be a problem, especially with ISR's, but again,
specific program design can obviate these concerns too.
If you can do it, and if it's what will make your problem
manageable, go for it.
Norm
----- Original Message -----
From: Ken Emmons, Jr. <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Friday, December 07, 2001 2:04 PM
Subject: RE: [rtl] malloc, timers, and crashes.
> Hi Norm,
>
> Yes, I am actually proposing a pre-allocated memory routine. I am
not interested in accessing memory through the linux kernel per se
(although if such a mechanism existed I would use it). What I do want
to do is to have a memory pool available that gets allocated at load
time and dispatched to threads upon need. I started to write a memory
pool interface for the specific need that I had but I was thinking,
why not make it generic??
>
> I was going to call the routines rt_malloc() and rt_free() unless
this would not be compatable in the mindset of what malloc does. I
guess by calling it rt_malloc() you are assuming that it does not
block (which it doesnt), it is relatively quick (it is), and that
there will be tradeoffs (there are). The main tradeoffs are its fixed
size, which I feel can be handled by proper use of the functions and
proper care (we are RT programmers and always need to be careful after
all).
>
> I am almost done with a simple implementation and it looks like it
will work (famous last words, considering I haven't event tried to
compile it yet! hehe :o) I will try it out.
>
> Hmmm... Someone has just pointed out to me that RTAI has a dynamic
memory manager available already. It looks like my code may not be of
much value if I end up switching to RTAI. I'll finish it on general
principle and so I can finish my code that prompted this whole thing
using RTLinux. Hmm.. another reason to port my stuff to RTAI. Are
there any real technical disadvantages to RTAI (coming form people who
actually use both RTOS's ).. everything I have seen has looked like
speculation or a Holy/Philosophical decision. Please, no flames .. I
am new to this list, I dont mean to cause problems!! :o)
>
> thanks.
>
> ~Ken
>
> -- [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/
>
-- [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/
