New deffinitions for RealTime, MultiTasking and MicroKernel.

JJeronimo · **Joined:** Wed Oct 18, 2006 3:29 pm **Posts:** 202

I posted this in a newsgroup in response to a guy who asked to explain him some definitions of Multiprogramming and Multitasking that he had read somewhere...

I, in comp.os.coherent, wrote:

arash.zaryab AT gmail DOT com had written:
> 2-"Multitasking (i.e., time sharing) is a type of multiprogramming
> that is useful for inter-active systems". (How? and Why?)

Multitasking is useful for inter-active systems (and not so useful for
non-interactive ones) because it allows one program to respond to the user
(ideally, in a real-time manner, this is, as soon as the request is made,
the system responds on it (and concludes it before doing anything else, in
case of hard real-time)) while another one is waiting for the kernel, the
hardware or another program (through the kernel, of course...).
Multitasking is not needed for e.g. your digital wristwatch, because
watches do not require interactiveness. They work alone.

Multitasking can to some extend be seen as the opposite of real-time.
That's because if the processor time is entirely distributed through
scheduling, then all the real-time performance gets killed.

In classical multi-tasking capable OS, the only code that is real-time is
that running in kernel mode.
If you have a micro-kernel with no interrupt handling capabilities (ok,
this doesn't exist because no one would code such a ****!), then you will
have an example of what I presented in the sentence before the above one.
That's because in a micro-kernel the drivers work in user-mode, and thus
additional work is needed to make sure that those drivers have some sort of
real-time responsivity. This additional work is not need in monolithic kernels.
So, micro-kernels can be seen as a radical state of multi-taskness: not
even the drivers are above other applications (that is, in terms of chances to control
the processor), but they are just like any other app.

> 1-Throughput is defined as the amount of work done per unit time.
> "The degree of multiprogramming in a computer system has direct
> influence on the throughput of the system".

I'm assuming that multiprogramming is really the same thing as multi-tasking...
If the time spent by a program while it waits for someone is not wasted but
instead is used by another program to do computations (work), then you are
able to increase the throughput of the system as a whole.

PS: Of course, just like everything, the perfect OS (if such a thing is
even possible) is a combination of all the above approaches, thus
equilibrating throughput and responsiveness, which are both good predicates...

JJ

Three important correlations:
* Multitasking is the opposite of real-time;
* Micro-kernels are the Rococo of multi-taskness;
* Micro-kernels are the opposite of real-time...

JJ

JJeronimo · **Joined:** Wed Oct 18, 2006 3:29 pm **Posts:** 202

Conclusion: lets all code mono-tasking operating systems so that we have Real Time at nothing's cost!

(just joking) :-)

JJ

Combuster · **Posted:** Mon Jul 09, 2007 2:05 pm

I tend to disagree with the impossible multitasking real-time system proposition. There exist systems that can run mutiple tasks while providing the real-time constraints.

In fact, there's a L4-based microkernel with real-time constraints according to wikipedia.

Colonel Kernel · **Posted:** Mon Jul 09, 2007 2:47 pm

Don't forget QNX...

I think you're conflating several issues that are orthogonal (scheduling policy, kernel architecture, and the definition of "multi-tasking").

Quote:

2-"Multitasking (i.e., time sharing) is a type of multiprogramming
> that is useful for inter-active systems". (How? and Why?)

Here's what my answer would have been:

That definition is probably 30 years old, because nowadays pretty much every system is interactive to some degree. "Multi-programming" in general means having more than one program loaded into the system and able to run, as opposed to batch-style processing where you loaded one program, ran it to completion (including long pauses for I/O), and then loaded the next one, etc. We're talking rolls of paper tape here -- it's that old. IMO such terms are now only useful to historians.

"Multi-tasking" used to mean just time-sharing on a uniprocessor, but I would argue it now encompasses thread-level parallelism on SMP, SMT, and multi-core processors as well. It's still too generic a term to be really useful to us OS-devers though, as we tend to assume that every interesting OS has some degree of support for multitasking.

miro_atc · **Joined:** Tue Jul 10, 2007 12:19 am **Posts:** 6

JJeronimo wrote:

Three important correlations:
* Multitasking is the opposite of real-time;
JJ

Not quite... The definition for a real-time system(RTS) is well known and has nothing to do with the number of tasks. What matters for a RTS is whether your system can respond correctly in a given time frame or not.

Now in terms of the real time, adding a multi-tasking capabilities to your system can make the things better or worse.
Worse, because the multitasking comes for the price of the overhead introduced from your kernel. So, the multitasking is eating from the time frame given to your system.
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.

In general, the overhead is well paid from the advantages of the multitasking, so most of the RTOSes provide us with multitasking enviernment ;-)

miro

JJeronimo · **Joined:** Wed Oct 18, 2006 3:29 pm **Posts:** 202

miro_atc wrote:

JJeronimo wrote:

Three important correlations:
* Multitasking is the opposite of real-time;

Not quite... The definition for a real-time system(RTS) is well known and has nothing to do with the number of tasks. What matters for a RTS is whether your system can respond correctly in a given time frame or not.

The point is not the number of tasks, but the scheduling nature of multi-tasking systems.
In this sense, their are extreme opposites of each other, because if you want real-time-ness, then you'll have to bypass the main idea of multi-tasking (here with exactly the same sense as time-sharing): the idea that programs get their chance to run based on the decisions of a scheduling algorithm. That's because in a RT system, there is one more factor that influences the decision: the arrival of external events, like mouse moves or key presses.

Quote:

Now in terms of the real time, adding a multi-tasking capabilities to your system can make the things better or worse.

Of course. But, as everywhere, you are allowed to mix many concepts so that you can benefit from both sides.
In Linux 2.4 (prior to kernel preemption), all the kernel code ran in Real Time.

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.

Quote:

In general, the overhead is well paid from the advantages of the multitasking, so most of the RTOSes provide us with multitasking environment ;-)

Of course a multitasking OS that is able to give you a nearly-real-time performance is more more interesting and challenging than a monotasking OS that gives you real-time performance at no cost. :-)

JJ

Colonel Kernel · **Posted:** Tue Jul 10, 2007 5:12 pm

JJeronimo wrote:

That's the problem. When you had only one task running, you could guarantee immediate response times for that task.

To take this idea further, what about interrupts? Is your idea of single-tasking to use polling instead?

Also, "immediate" response is not important for a RTOS. What's important is predictable response. Tasks must meet their deadlines, but that doesn't mean those deadlines are extremely frequent.

JJeronimo · **Joined:** Wed Oct 18, 2006 3:29 pm **Posts:** 202

Colonel Kernel wrote:

Don't forget QNX...

I think you're conflating several issues that are orthogonal (scheduling policy, kernel architecture, and the definition of "multi-tasking").

Imho they are not orthogonal between them, although you can combine them by increasing the presence of one characteristic while you decrease others.

Quote:

2-"Multitasking (i.e., time sharing) is a type of multiprogramming
> that is useful for inter-active systems". (How? and Why?)

Here's what my answer would have been:

Of course, my answer tried to go further than just explaining those terms!

Quote:

"Multi-tasking" used to mean just time-sharing on a uniprocessor, but I would argue it now encompasses thread-level parallelism on SMP, SMT, and multi-core processors as well.

Thread-level parallelism is no different from process level paralelism as, in general terms, threads are just processes that share something of their execution environment...
As of the multi-processing paradigms, nothing changes for the point of view of my response: multi-tasking still distributes the CPU time among many tasks, independently of the number of CPUs whose time is distributed.

JJ

miro_atc · **Joined:** Tue Jul 10, 2007 12:19 am **Posts:** 6

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

OSDev.org

New deffinitions for RealTime, MultiTasking and MicroKernel.

Who is online