On Thu, Sep 07, 2000 at 03:50:17PM -0400, Tony Mouawad wrote:
> I'm new to the RT world, but I'm curious... what significant challenges are
> there when working with dynamic memory and real time?  Just the term
> "dynamic" gives us an indication that the mechanism would be
> undeterministic... but what's worse case here?  Why is it impossible to have
> a "real time" dynamic memory manager?  At worst, nothing is "real time",


To illustrate:

Thread:
            loop:
                 if(get_a_buffer){
                           wait for an interrupt
                           copy data to buffer
                           dispatch buffer
                           }
                  else try_to_recover();
                  goto loop

Case 1: "get_a_buffer" may sometimes stall the thread
         Result: program may stop at any momement.
Case 2: "get_a_buffer" allocates from a pool that is used by other threads and 
             just returns failure if there is no free buffer.
         Result: program may fail at any input load depending on who else
                 uses the buffer pool.
Case 3: "get_a_buffer" allocates data from a static pool used only by this thread
                       and freed by the destination.
         Result: thread can handle sizeof(buffer_pool)/sizeof(buffer) outstanding
                 requests. If a dispatched buffer is known to be freed within K time
                 units and interrupts take less than K time units plus 
jitter+interrupt dispatch
                 + copy time ...  then there will never be a out of buffer failure.

So it's a subtle difference with big implications.  In the case of  Steve 
Papacharalambous 
module, things are more complex since he essentially manages a cache of memory and 
replenishes this cache from Linux when the system is not busy. I think this is an
especially dangerous method since it makes out-of-memory failures  harder to find by 
testing. I'm in favor of:
                 crank the input device up to full speed and see what happens
but to test our program above using a caching memory allocator we need
                 crank the input device up to full speed, make Linux busy and
                       also do something to exercise all other modules that may use 
                       the memory allocator so that they use max memory.

All that said and done, however, since implementing a cache memory pool is the work of 
maybe
an hour, at best, this discussion is more about philosophy of design than about 
anything concrete.


-- [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/

Reply via email to