Subject:
|
Re: Re: Scheduler patch
|
Newsgroups:
|
lugnet.robotics.rcx.legos
|
Date:
|
Wed, 10 Jul 2002 13:04:57 GMT
|
Viewed:
|
2554 times
|
| |
|
|
"Joel Uddén" wrote
> Thanks for the link, your solution of proportional timeslicing is more
> straightforward than mine which I like. The only downside would be that a
> high prioritized process would have it's wakeup conditions checked less
> frequently than a low prioritized process, which make no sense, but if the
> wakeup/sensor handling will be moved from the scheduler the problem will • not
> occur.
Actually, each task gets equal "wakeup" checking. The only difference
between a low priority task and a high priority task is that the high
priority task gets a larger time-slice when it is awake. This is not an
optimal solution; that I know. However, I think it might be a step in the
right direction.
If the sensor readings can be queued in some way... then each wakeup
function could search the queue. This would give each task (regardless of
priority) a better chance of seeing a sensor event. The accuracy would be
dependent on the queue size, number of tasks and the frequency of the sensor
events. I imagine that even a small queue could improve accuracy greatly.
<snip>
> Well, from my experiences the sensor accuracy is MUCH better with the dat4
> implementation. It would be nice with a smaller/simpler solution though.
I have not tried the dat4 implemenation, but I have read a good bit of the
code. It looks to be a very good implementation.
> Can you give me an example of when a user needs to have several processes
> running to solve a task. I'm probably stupid not finding any :P
Of course there is no NEED to have several processes to solve a task. I
think it is somewhat easier to write a multi-process program for dealing
with real-time events. You can accomplish the same thing with a
state-machine or a big switch/case or if/then/else statement. LOL.
One advantage to a multi-process program is that each process can be
independent from the others. So if one crashes, it is more likely that the
other processes can continue there operation. Also, with dynamic
priorities, the program can modify its behavior in ways that a single
process program cannot. (Giving priority to certain code for a short
period, then switching priorities to better suit the changing environment).
Thank you for your comments!
// Joe
|
|
Message has 1 Reply:
Message is in Reply To:
 | | Re: Re: Scheduler patch
|
| (...) Thanks for the link, your solution of proportional timeslicing is more straightforward than mine which I like. The only downside would be that a high prioritized process would have it's wakeup conditions checked less frequently than a low (...) (22 years ago, 10-Jul-02, to lugnet.robotics.rcx.legos)
|
17 Messages in This Thread:
 
 
- Entire Thread on One Page:
- Nested:
All | Brief | Compact | Dots
Linear:
All | Brief | Compact
This Message and its Replies on One Page:
- Nested:
All | Brief | Compact | Dots
Linear:
All | Brief | Compact
|
|
|
|
