OSDev.org

hi.
I think a task is a process, not a thread.
but someone told me, in embedded os, a task is a thread.is that right?

A task can be a thread, and a thread can be a task, but they can also be seperate. It depends on the design of the OS and software. Threads are normally sub-sections of a task, however, some tasks need only one thread, and can there for be thought of as a thread that the OS is running (hence calling it a thread or a task). In other cases, a task has multiple threads running, and is refered to as a task. There are many ways to think of threads and tasks, sometimes there isn't a distinct line between the two.

Now, for a process, I typically consider a process something that runs in an independant memory space, for example, you launch notepad and windows allocates it's memory and sets a new user level virtual memory space for it. This is a process. It cannot interact with other process' except through kernel calls. A thread is either local to a process, or local to the kernel. A task is similar to a process in my mind, but the way windows looks at it, normally a task is something that you can interact with, like notepad, while a process can be something like a service running in the background that you have no direct interaction with (although, if it's a kernel level process, you could call it a thread as well). Like I said, no distinct lines, and different OS's consider them slightly different things, some OS's don't distinguish between them.

...and who or what decides how many threads the process will have?
Programmer or OS?
And how much is execution more efficient when using multi-threading against multi-processing.

I'm confused....
So we can have:
1. multi-processing with multi-threading
2. multi-processing without the threads
3. single-processig with multi-threading
...right?

Dario wrote:...and who or what decides how many threads the process will have?
Programmer or OS?

Traditionally, this is the domain of the application - if an application requires an additional thread, it makes a system call to spawn that thread.

And how much is execution more efficient when using multi-threading against multi-processing.

Let me try to clear up some concepts for you. Bear in mind that lots of developers seem to use these terms in different ways which is where a lot of the confusion comes from. Here's my take on it:

• Task == Process: I consider these terms to be pretty much interchangeable. A Task has its own Task Space. This means that a Task sees its own memory space only (it cannot mess directly with data belonging to other tasks).
• Thread: Each task may have one or more threads. Each thread has its own stack (for local variables, return values and so on) and Instruction Pointer value. Each Thread belonging to a particular Task sees the same memory space. This means that in theory a Thread could mess with the global data belonging to another Thread (because all Threads belong to the same Task space).
• Multitasking: The OS's ability to switch between Tasks, giving the impression that multiple applications are running at the same time (really, only one Thread of one Task will be active at any time). This can be achieved through software or hardware mechanisms.
• Multithreading: This simply relates to the fact that the OS supports multiple Threads per Task, not just one Thread per Task.
• Multiprocessing (most commonly SMP): This normally refers to an architecture with two or more processors, such as the Intel Core 2 Duo (which has 2 physical cores) or the Pentium 4 (which has one physical core, but 2 logical cores due to Hyperthreading). This means that multiple Tasks/Threads can actually be run simultaneously. With SMP, all Cores share the same physical memory.

Now, where the confusion comes is that some OSes just give the appearance of having Threads, whereas some have a very strict difference between a Task or Thread. Using the above definitions, if an OS only has Thread support, those Threads are part of the same Task if they share a linear memory space.

I hope that clears a few things up and am aware that a few of the definitions are oversimplified or that people may not agree with some of the terminology

Cheers,
Adam

Thanks...

So in practice....CPU jumps to another process, executes couple of threads and then jumps to some other process and does the same thing there. And what happens when interrupt occurs...does it interrupt the task(process) or a thread?
If it interrupts the thread how does it store current CPU state and how is that different from storing the same state in the term of process...

Dario wrote:So in practice....CPU jumps to another process, executes couple of threads and then jumps to some other process and does the same thing there.

This varies between architectures, but for the x86, what basiclly happens is this:

• The CPU is running a piece of applications code (Task 1, Thread 1).
• A timer interrupt happens. The interrupt handler calls the Scheduler (this is a software part of your OS) to decide which thread is next in line to run - there are loads of algorithms for this depending on the OS design.
• The scheduler has decided that Task 2, Thread 3 needs to run next. We save the state of Task 1, Thread 1 (this is actually mainly done by the CPU on an x86).
• The state of Task 2, Thread 3 is loaded. This may be as simple as loading a page directory and stack pointer.
• The CPU returns from the interrupt handler, but this time returns to, Task 2, Thread 3 as instructed by the scheduler.
• After a while, an interrupt happens....

The scheduler is generally looking at the Thread to run next, not the Task. This means that the next scheduled item could be Task 2, Thread 1 or it could be Task 1, Thread 5 or ...

In a 4 core multiprocessing system, you may end up with all 4 cores running separate Threads from Task 1, or each core could be running Threads from separate Tasks. It all depends on the scheduler and whether your OS has an option to set Task Affinity.

And what happens when interrupt occurs...does it interrupt the task(process) or a thread? If it interrupts the thread how does it store current CPU state and how is that different from storing the same state in the term of process...

In an x86 processor, for any user-mode application which is interrupted, the CPU will do the following automatically in order:

• Switch to an OS-level Stack.
• PUSH the user-mode stack information (SS and ESP).
• PUSH the contents of EFLAGS.
• PUSH the user-mode code segment and instruction pointer (CS and EIP).
• JUMP to your Interrupt Service Routine (ISR).

The scheduler ISR (which you have written) will then generally push the general purpose and segment registers and save the stack pointer. Once the Scheduler has chosen the next task, the whole process is reversed, with the addition of restoring the task's page directory (which dictates a task's memory space).

All this means that all you need to do is switch stacks and you end up restoring a different task.

If you don't have task switching, you would expect a timer interrupt to happen "transparently" to the task (the task is not aware a switch has occurred). For task switching, you should expect the same to happen - the thread is asleep until its stack is loaded.

For a load more information, see the Intel Manuals which can be oredered FOC, along with our own wiki and http://www.osdever.net.

Cheers,
Adam

The one thing that was never really clear to me until explained, was that every thread (using AJ's definition) usually has BOTH its main userspace stack (holding return values and local variables) AND a little stack that is stored in kernelspace, for the OS-level stack that he mentioned -- which is used to store the thread's state when the thread is swapped out.

Thanks AJ! It's much more clear now.

Glad it helped

The scheduler is generally looking at the Thread to run next, not the Task. This means that the next scheduled item could be Task 2, Thread 1 or it could be Task 1, Thread 5 or ...

This raises problems of fairness between processes. It depends on the policy your scheduler adopts, however. For instance, mine runs each thread in a process for a given amount of time, and when the sum of all the nanoseconds that the threads have ran reaches X, it clears that sum and does a process switch.

Like I said above, not all OS's treat everything the same. Some consider some things equals, while others divide them. This is why there is so much confusion, because there is no single definition. A task can be a thread, or a thread can be a process, and a process can be a task, but that doesn't always make them equal .

The way I like to look at it is:

* A process has an address space and contains one or more threads.
* A thread is what gets executed. If there's only one thread, the application is single-threaded.
* A task is a hardware mechanism (see IA-32 & Intel 64 manuals) for implementing threads.

Love4Boobies wrote:The way I like to look at it is:

* A process has an address space and contains one or more threads.
* A thread is what gets executed. If there's only one thread, the application is single-threaded.
* A task is a hardware mechanism (see IA-32 & Intel 64 manuals) for implementing threads.

Yes, which your definitions are correct, in some specific cases. But, what about software based multi-tasking? There isn't a hardware mechanism for implementing threads, you are using push/pop's and timer based interrupts (unless you are saying a timer interrupt is a task, then I disagree, because it's an interrupt, not a task). What if you substitute the word "application" in your above example for system service, or driver. Does it run in kernel space? Is it a micro-kernel and run drivers in user-space? Are they threads of the kernel, or applications that are single threaded? A process typically has it's own address space, but what about developing on smaller architechures that only have a single address space? What about my above example about drivers and system services, if they run in user-land for a micro kernel, are they process', applications, threads, etc? Look no further than 'task' manager in windows to see how they consider the terms. Like I said, you can view them however it helps you, but there are no definitions that work in all cases. If we know more about the context of the OS that he is using, maybe we can give better definitions, otherwise, I say don't get caught up in the terms, just know that there are differences, but typically from what i've seen (and these sound generic, because they are).

Process : Contains one or more threads, can be a task (user application) or driver/system service
Thread : Piece of code that gets executed, either by the kernel directly or a process/task.
Task : Can be interchanged with process, but typically this is something that the kernel runs that the user is doing, aka word processor, internet browser, etc.

As I said, these are generic terms that can change in meaning, so don't get caught up on definitions.

You're right, I didn't think about that...