Subject:
|
Re: Multitasking
|
Newsgroups:
|
lugnet.robotics
|
Date:
|
Fri, 14 Jan 2000 18:57:11 GMT
|
Viewed:
|
817 times
|
| |
|
|
Hi John,
I agree that on an interupt-driven system, multitasking is very useful for
problems that require precise timing. As soon as the problem occurs, an
interupt is fired and the appropriate code handles the problem.
But, as you noted, the RCX doen't work that way. The normal pattern is a task
runs some code, goes to sleep to so that other tasks have processor time, wake
up and run the code, go back to sleep, etc.
My original worry about stripping out the multitasking was just as you stated:
> while(1) {
> if(out_of_balance()) { balance(); }
> if(hit_something()) { avoid_obstacle(); }
> /* ...other tests and actions... */
> }
> If the out-of-balance condition occurs just after the test, but a bumper
> is activated and avoid_obstacle runs, it will be way too late by the time
> balance() gets called.
...but when I did it, I actually found that response time improved! I believe
this was because I was able to get rid of having to put tasks to sleep. The
sleep time was longer than the time it took to run code like out_of_balance()
and hit_something().
Of course, I'm not doing a balancing bot, I'm doing a simple cruise and avoid.
Still, response time improved and I would think that would help a balancing bot
too.
David Leeper (thinks the key here is the relationship between sleep time and
execution time)
In lugnet.robotics, John A. Tamplin writes:
> On Fri, 14 Jan 2000, David Leeper wrote:
>
> > I was thinking this over last night and was wondering about how sleeping a • task
> > would affect an application that requires precise timing. In the bicycle
> > example, what would happen if the balancing task was asleep when the bicycle
> > began to tip?
> >
> > I think multitasking is certainly useful in situations where the tasks are
> > disjoint, such as driving the robot and sending a message over the IR port. • But
> > when the tasks need to work together closely, the sleeping issue worries me.
>
> Actually, this is precisely the case where multitasking works best. A
> single-threaded application has to poll for events that it is interested in.
> Regardless of the priority of a particular event, that event has to wait
> until the application polls for it. You can adjust this somewhat by polling
> more important things more frequently, but it is still a problem. For
> example:
> while(1) {
> if(out_of_balance()) { balance(); }
> if(hit_something()) { avoid_obstacle(); }
> /* ...other tests and actions... */
> }
> If the out-of-balance condition occurs just after the test, but a bumper
> is activated and avoid_obstacle runs, it will be way too late by the time
> balance() gets called.
>
> In a traditional multitasking environment, you have separate threads running
> at appropriate priorities. In your example, the balancing task would be one
> of the highest priorities, while things like avoiding obstacles would be
> lower and tasks like finding a target to shoot would be lower still. Some
> hardware detects that an out-of-balance condition exists, triggers an
> interrupt, which wakes up the balancing thread. Since it is the highest
> priority thread, it runs immediately.
>
> Note that this does not necessarily apply to all systems that are called
> multitasking -- specifically the standard Lego software -- but this should
> give you an idea of the value in a real-time environment.
>
> John A. Tamplin LiveOnTheNet.COM, Inc.
> jat@LiveOnTheNet.COM 2104 West Ferry Way
> 256/705-7007 - FAX 256/705-7100 Huntsville, AL 35801
|
|
Message has 1 Reply:
 | | Re: Multitasking
|
| (...) That isn't the RCX, but rather then standard Lego firmware. legOS avoids most of the limitations of the standard firmware, and there is still room for more interrupt-driven approaches. (...) The difference is that if your bot hits something (...) (25 years ago, 14-Jan-00, to lugnet.robotics)
|
Message is in Reply To:
| | Re: Multitasking
|
| (...) Actually, this is precisely the case where multitasking works best. A single-threaded application has to poll for events that it is interested in. Regardless of the priority of a particular event, that event has to wait until the application (...) (25 years ago, 14-Jan-00, to lugnet.robotics)
|
9 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
|
|
|
|
