JJeronimo wrote:
Quote:
But from other side the things can get better because in the real life your system has to respond to many events, some of which can be more urgent than others. Here the multitasking helps you to use the CPU more efficiently and the critical tasks will get priority so at the end of day *all* of the events will be processed in time.
That's the problem. When you had only one task running, you could guarantee immediate response times for that task. Once you begin distributing CPU time slices among many jobs, you'll need to evaluate the urgency of the various jobs that you are running, so that you can decide which of them are ran first when they need so. And then, you won't be delivering every process the opportunity of a true Real Time response.
When you have only one task running, the only thing you can guarantee is that it will get 100% of the CPU. Is this a real-time system??
The answer is: "we just don't know". It could be a real-time "task" if it meets all the deadlines, but we can't say this without knowing your task...
The claim that "single task will guarantee immediate response" is not quite correct because you can't be certain.
Imagine the following application. Let's say you have a device that plays streamed video. You have two tasks - one to receive the video stream and another to decompress and render it to the sceen.
With multitasking enabled you will have two threads and you can have a predictable system. Assuming that the network task has higher priority it will respond to any incomming packet and request another one within known time frame. This time frame includes the context switching and the time for the packet processing.
Now how can you do this without multitasking ??
You will have a video decompression and when and how you will check the network?
Once per frame? Then you will be too lazy with the network...
Once per row? Then you will have to execute too many "if(network)" in your video function.
Obviously if you check the network status too often then you will have a reasonable response time, but at what price? You will kill the CPU when there is no network activity. So you can gurantee the network response time but you can't gurantee good video decompression speed or vice-versa.
And this is examle with just 2 taks, in the real world you have many task to do.
With other words, if you have many things to do and if you want to do them in real time, the ONLY option is the multitasking approach.
And the claim:
Quote:
* Multitasking is the opposite of real-time;
is really true only when you have one thing to do.
But then you can't use the word "system"... because "system" means that you have lots of things and of course if you don't have a system you don't need multitasking.
With other words you compare apples and oranges
The correct claims I think can be:
Multitasking is the opposite of real-time
element
or
Multitasking is the basement for real-time
systems