Re: thread and process
- From: Rainer Weikusat <rweikusat@xxxxxxxxxxx>
- Date: Sun, 24 Aug 2008 12:39:48 +0200
asit <lipun4u@xxxxxxxxx> writes:
Linux treats threads like processes. Then what is the advantage of
thread over process??
Wikipedia isn't necessarily a reliable source of information :->.
As stated above, this sentence is nonsensical: A process is defined as
a set of system ressources, most prominently, an address space separate
from the address spaces of all other processes, shared by n threads of
execution, n >= 1.
At the implementation level, there are three different ways to
implement multithreading-support, called 1:1-threading, where each
thread of the process is visible to (and scheduled by) the scheduler
in the kernel, 1:n-threading, using a userspace scheduler for threads
the (process) scheduler in the kernel is completely unaware of, and
m:n-threading, utilizing two cooperating schedulers, with the kernel
scheduler 'seeing' m so-called 'light-weight processes' onto which the
userspace scheduler multiplexes n threads of execution (with m < n,
obviously). These were invented because a lot of the state information
associated with a traditionally implemented 'UNIX(*) process', eg
uids, gids, cwd, table of open files etc, must remain per-process in
multithreaded applicatins and because context-switching in userspace
has a lower overhead than trapping into the kernel to accomplish the
same. Since Linux is not UNIX(*), it didn't inherit the UNIX(*)
process implementation, so there was no need to create a separate
less-baggaged kernel abstraction for threads and the assumption that
the higher overhead of using a unified scheduler in the kernel would
matter practically turned out to be wrong: The Linux-kernel uses
something represented by a struct task_struct containing pointers to
shareable ressource structures internally to represent 'kernel
schedulable entities' and 'processes' exist only virtually, insofar as
a set of such tasks sharing certain ressource structures 'looks like'
a UNIX(*)-process to application code to some degree: For instance,
until Linux 2.6, such a virtual process didn't have an ID-number of
its own, only each of the tasks comprising it had one.
The reason some people (eg R. Love in 'Linux Kernel Development')
erronously claim that 'Linux threads are just processes' is because
this implementation evolved from the ancient (IIRC, pre-2.0) kernel
implementation of multi-process support, which exited at a time when
there was no kernel support for multi-threading in Linux.
.
- References:
- thread and process
- From: asit
- thread and process
- Prev by Date: SIGPIPE on cygwin
- Next by Date: Re: vi in linux to vi in unix
- Previous by thread: Re: thread and process
- Next by thread: Re: thread and process
- Index(es):
Relevant Pages
|
