Subject:
|
task switching strategy?
|
Newsgroups:
|
lugnet.robotics.rcx.legos
|
Date:
|
Fri, 21 Apr 2000 17:46:15 GMT
|
Reply-To:
|
sjm@judgement!AvoidSpam!.com
|
Viewed:
|
1333 times
|
| |
|
|
I've been wandering through the kernal comparing it to
similar kernals I have known or written, trying to understand
the design choices.
It appears that task are only switched at the 1ms timer
interrupt and at yield() function call. yield() is
only called by tasks for various reasons.
I also find that some of the the overhead of managing task
state changes are handled by the switcher.
Finally it seems that the lcd is refreshed in the scheduler.
Doesn't this belong in the timer code. Why would it want
to be called from a task yield? (NOTE: A closer look shows
this change has already been made. The old code remains
under manifests which is where I got confused.)
At first blush this seems to violate several basic rules of
real time OS design so I am trying to understand the constrants
that lead to this.
The first rule is that searching for new tasks to run is a
high frequency activity which shouldn't be burdened with
low frequency work. In particular changing a task's state
happens seldom and only based on special events.
If I were starting a design from scratch I would use the
following principals:
1) Keep the scheduler as light and fast as possible.
2) Only call the scheduler when activities happen that
may change task state, probably as a result of setting
a semaphore.
3) Edit the task queues directly when events happen that may
change them. For example when a task is marked as
a ZOMBIE. Note: This is already done when a task is created.
It seems inconsistant to add things to the queue at task time
and delete them at schedule time.
3) Replace the current polled event scheme with something
generated by the actual activities that cause change, mostly
adding hooks with semaphore calls and potential scheduling
calls to all interrupts. Events should be pushed not polled
for. If you must have polled events move the polling to the
timer code and out of the scheduler itself.
Given the above I would change the scheduler slighty to have a
dirty flag which is set by anything that changes task state.
The scheduler could then immediately exit if the dirty flag is
clear. The most common case a scheduler sees is that there is
no change in running task. This case is usually well worth
optimizing.
The point of all this of course would be to reduce context
switch overhead.
So what am I missing? Certainly the current scheme is elegant;
not a trivial issue. That makes it easy to understand and
maintain. Quite possibly the current CPU overhead is trivial and
my suggestions would have no benefit. It is only in my gut
that the idea of extra work every millisecond seems bad. Perhaps
the actual numbers are acceptable. For example a 100 usec overhead
of 10% would be fine. Perhaps someone has toggled a motor bit
at the beginning and end of the timer interrupt and measured the
time on a scope?
By the way, in spite of these concerns I think the code is quite
excellent. It is clear and easy to read. I picked up the
major points in just a small number of hours of code reading.
This code is a delight to read. Also lest I seem merely a
complainer I hereby volunteer to experiment with any of these
potential changes if anyone thinks they might be beneficial.
More likely is that the changes I propose have negative side
effects that I don't understand which will be clearly
corrected by some poster.
Regards,
Steve Morris
|
|
Message has 1 Reply:
 | | Re: task switching strategy?
|
| On Fri, 21 Apr 2000, Steve Morris wrote: <snip lots of discussion, some of which I understand now and the rest of which will probably make more sense after I take OS next semester.> (...) I think the big thing is that virtually no one write CPU (...) (24 years ago, 22-Apr-00, to lugnet.robotics.rcx.legos)
|
2 Messages in This Thread:
 
- Entire Thread on One Page:
- Nested:
All | Brief | Compact | Dots
Linear:
All | Brief | Compact
|
|
|
|
