Task vs. process, is there really any difference?

I'm studying for my final exams in my CS major on the subject distributed systems and operating systems.

I'm in the need for a good definition for the terms task, process and threads. So far I'm confident that a process is the representation of running (or suspended, but initiated) program with its own memory, program counter, registers, stack, etc (process control block). Processes can run threads which share memory, so that communication via shared memor开发者_JAVA百科y is possible in contrast to processes which have to communicate via IPC.

But what's the difference between tasks and process. I often read that they're interchangable and that the term task isn't used anymore. Is that really true?

The term "task" is mostly used in the context of scheduling*, when it can refer to either a thread or a *process***, that can be scheduled to run on a processor.
From the scheduler's point of view there might be little-to-no difference between a thread and a process - both represent a task that must be scheduled.

Recently, the term "task" is gaining more-widespread usage, especially among .NET developers, thanks to e.g. the Task Parallel Library. Within it, tasks are units of work that can be scheduled to run on threads from a pool of worker threads.

_{* e.g in kernel programming, esp. on Linux
** theoretically, you could make up your schedulable entities}

Processes and threads are the mechanics, task is more conceptual. You can queue a chuck of work to run asynchronously, on windows with .NET for example, this gets run on a thread from the thread pool. With OpenMP, a task would be part of your for loop running on one core.

Minor related notes: on windows, there are also jobs, thread pools, and fibers for mechanics. Also, a process is nothing without at least one thread running.

I'm old-school. Strictly speaking, "processing" is work performed in memory that does not involve input/output operations. A "task" is a process that includes I/O operations. Accordingly, a multi-tasking system can run concurrent I/O streams, whereas a multi-processing system must task switch its I/O. PC's have only one mouse, keyboard, etcetera, so they are not multi-tasking systems to me. I consider a mainframe to be a multi-tasking system.

Threading is a technique for switching processing context. Allows a physical processor to drive multiple processes. No direct relationship to tasks.

It depends on your context.

In Ada, a task is a construct in the programming language to enable concurrency.

It isn't specified what operating system construct should be used to implement it, but it allows shared-memory between tasks, so a thread would be a more natural implementation.

I think it's dependant of the underlying operating system which term is used.

You could also think of task as a running piece of code. Then a part of a thread or a part of a process could be a task.

Process Process is a naturally occurring or designed sequence of operations or events, possibly taking up time, space, expertise or other resource, which produces some outcome. A process may be identified by the changes it creates in the properties of one or more objects under its influence

Thread Threads are similar to processes, in that both represent a single sequence of instructions executed in parallel with other sequences, either by time slicing or multiprocessing. Threads are a way for a program to split itself into two or more simultaneously running tasks

Task a set of program instructions is loaded in memory

A task and a process are usually similar when used in terms of OS : they are both a set of instructions loaded into memory to be executed by the processor. As all modern processors uses Time sharing and context switching for process execution, the difference lies in the number of processors , i.e if one processor is executing multiple processes, it's a multitasking system and if there are multiple processors executing multiple processes(or different parts of a process), it's a multiprocessing os