Subject:
|
Re: multiple "execi" with different priorities
|
Newsgroups:
|
lugnet.robotics.rcx.legos
|
Date:
|
Fri, 23 Feb 2001 09:24:49 GMT
|
Viewed:
|
1403 times
|
| |
|
|
In lugnet.robotics.rcx.legos, Bernardo Dal Seno writes:
> "Ross Crawford" <rcrawford@csi.com> writes:
>
> > must get a slice before any lower priority tasks get any slice. And remember
> > that LegOS uses co-operative multi-tasking, not pre-emptive, so your tasks • have
> > to specifically relinquish control before any other task will be scheduled.
> > Someone please correct me if I'm wrong....
>
> Actually legOS multitasking is preemptive :-)
Yes, I actually went & checked after I'd posted. Maybe I should've checked
before 8?)
Anyway, Stig Nielsson emailed me the following, which explains it a lot better,
and will probably be useful for Thanasis to work out the original problem:
----------------------
1)
legOS _does_ use pre-emptive multitasking. Here is an ultra short
description of how it works:
By default a task is executed for 20 ms. before being preempted.
A task is preempted by the function systime_handler function defined in
systime.c which handles the 1 ms. timer interrupts that drives the system. If
the 20 ms. of the current task has elapsed, systime_handler calls tm_switcher
tm.c which saves all registers of the current task on its stack,and then call
the scheduler. The scheduler designates a new task to execute and returns to
tm_switcher which copies the context of the new task into the registers and
returns to systime_handler which just returns to the code in the new task.
Tasks however, may voluntarily yield control of the processor by calling
yield(). :-)
2)
When the scheduler looks for a new task to execute, it always starts
with the highest prioritised task, and thus starvation of a lower prioritised
task is possible when the priorities are changed, what probably is your
problem.
Check your code, remembering that if several tasks are waiting to execute, the
prioritised are always selected first, e.g. if the task with prio 10 and
the task with prio 12 both wait on the same semaphore, and the task with prio
11 posts the semaphore, then it is the task with prio 12 that is allowed to
execute the next time the scheduler runs.
Another possibility is that you encounter the problem of priority inversion,
where lower prioritised tasks holds resources (e.g. a semaphore) needed by
higher prioritised tasks but I'm not sure if that is relevant in this case.
- Stig Nielsson
----------------
Thanks, Stig!
Regards,
ROSCO
|
|
Message is in Reply To:
5 Messages in This Thread:
 
  
- Entire Thread on One Page:
- Nested:
All | Brief | Compact | Dots
Linear:
All | Brief | Compact
|
|
|
|
