Subject:
|
Re: My problems with adding a Best Fit algorithm for memory management to kernel/mm.c
|
Newsgroups:
|
lugnet.robotics.rcx.legos
|
Date:
|
Thu, 11 Dec 2003 18:44:00 GMT
|
Viewed:
|
4013 times
|
| |
|
|
Mark Riley wrote:
[snip]
> Now, when you turn the RCX back on, it starts up and allocates memory for the
> various kernel tasks. With a first fit malloc() algorithm, it just so happens
> that the tasks get allocated the same memory that was released on power off. So
> everything is peachy. But, with the worst fit algorithm in place, the program
> manager task gets moved to another address and so the downloaded program PID
> points to a non-existent task.
>
> In the (extremely) unlikely event a user program starts up a task and it gets
> allocated to 0xAFDA, then when this task exits it will also unwittingly free up
> the memory used by the downloaded program (unbeknownst to the program manager)
> and a crashed OS will no doubt quickly be the result.
>
> Simply changing the PID for downloaded programs to an impossible value (like 1)
> would solve the problem.
This is easy enough to implement (1 or 2 lines), but raises the
question: Should these memory strategies be included with BrickOS (with
a config.h flag to control it)?
I am sure the educators would rather leave that as an exercise for their
students. :)
If yes, then BrickOS could include the safe-guard (aka hack) to ensure
this doesn't happen (the freeing of the program memory).
In addition, using the worst fit, or other memory strategy, could enable
a situation where a kernel task would fail to start upon power on
(largest free memory block is too small). Example, idle task fails to
start because it cannot allocate it's stack; IIRC, this would be bad.
// Joe
|
|
Message is in Reply To:
14 Messages in This Thread:
  
 
- Entire Thread on One Page:
- Nested:
All | Brief | Compact | Dots
Linear:
All | Brief | Compact
|
|
|
|
