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?
- posted
14 years ago
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?
Hi
For me (I did not check official definition, so I can be wrong), the term task is used in smaller OS where each "task" share the same environnement. Moreover, a task can not own threads.
The process is used on more evolved OS, each process as it's own (virtual) memory space so data can not be share directly between each process.
The thread is link to a process and share the same memory space that the parent process and others threads in the same process.
So, a thread is a sort of task in a process.
That's how I see things but I can be wrong.
-- Guillaume Chevillot
Technically a process is defined by its operating system. Generally in embedded system I would call all the tasks threads and that the whole thing is one process, as you only have one memory space.
It becomes CPU depedant also. Some CPUs for example can map memory independanly for each process, allowing you to run copies of them that are seperate, even though the code is accessing the same memory address, because it maps memory for each one to different physical memory. If multiple tasks are running on the same memory mapped space, then they are threads, and combined they are a single process.
It depends on who's using the terms. AFAIK, there's no "official" definition of what the terms mean... "Thread" seems to be the buzzword de jour.
Definitely not.
In the Unix world it's generally this:
process: has it's own priviate virtual address space and execution context.
thread: shares an address space with other threads, but has a private execution context.
task: something your boss tells you to do.
In the process control/instrumentation world world, "process" refers to the fuild or material being controlled or measured (e.g. the oil in a pipeline, the wort in a fermenter, etc.
In the embedded world, any of them can mean anything. You'll have to ask the speaker/writer what he means.
-- Grant Edwards grante Yow! Did you move a lot of at KOREAN STEAK KNIVES this
I sort of agree with both posts. Process and thread are actually quite well defined within some communities, as per Grants post. In the embedded world you tend to see thread and task used interchangeably. I use 'task' for FreeRTOS.org as the target processes generally have only one address space, so using thread 'might' be confusing to some, but basically I mean the same thing.
-- Regards, Richard.
Not to me. A task is a job to do. A process is something that operates on a computer without affecting other processes, or being affected by them (except for known and documented OS communication mechanisms).
A thread is something that operates time independant of other threads (in a process), but has common memory and peripherals with all those other threads.
-- [mail]: Chuck F (cbfalconer at maineline dot net) [page]:
well so those who say "it depends on who you ask" are correct. In DPS, a task is what you would call a process; I call a process a group of tasks which have access to the same "common" DSCT (all tasks have a system, a user and a common DSCT address & size from the systems point of view).
I do not use "thread" because I have seen it used in a hardware context - IIRC MIPS allow you to run two tasks (your processes) simultaneously - well, a lot more simulataneously than time slice after time slice as we normally know it. They share the ALU & pipeline & whatever they have inside on a per clock basis, i.e. if an operation in task 1 does not use the resource pipeline entry say #1 of task 2 needs then just task 2 progresses one clock cycle as well - something like that, I just read it, never used MIPS. Anyway, however close my description may be they call these two tasks "threads".
Didi
------------------------------------------------------ Dimiter Popoff Transgalactic Instruments
------------------------------------------------------
Original message:
ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.