¿Cuál es la diferencia entre un proceso y un hilo?

https://stackoverflow.com/questions/200469

03-07-2019
|

Pregunta

¿Cuál es la diferencia técnica entre un proceso y un subproceso?

Tengo la sensación de que una palabra como "proceso" se usa en exceso y también hay hilos de hardware y software. ¿Qué hay de los procesos ligeros en lenguajes como Erlang ? ¿Hay una razón definitiva para usar un término sobre el otro?

Solución

Tanto los procesos como los hilos son secuencias de ejecución independientes. La diferencia típica es que los subprocesos (del mismo proceso) se ejecutan en un espacio de memoria compartido, mientras que los procesos se ejecutan en espacios de memoria separados.

No estoy seguro de qué " hardware " vs " software " hilos a los que podría estar refiriéndose. Los subprocesos son una función del entorno operativo, en lugar de una característica de la CPU (aunque la CPU normalmente tiene operaciones que hacen que los subprocesos sean eficientes).

Erlang usa el término " proceso " Porque no expone un modelo de multiprogramación de memoria compartida. Llamándolos " hilos " implicaría que tienen memoria compartida.

Otros consejos

Proceso
Cada proceso proporciona los recursos necesarios para ejecutar un programa. Un proceso tiene un espacio de direcciones virtuales, un código ejecutable, mangos abiertos a objetos del sistema, un contexto de seguridad, un identificador de proceso único, variables de entorno, una clase de prioridad, tamaños de conjuntos de trabajo mínimos y máximos y al menos un hilo de ejecución. Cada proceso se inicia con un solo subproceso, a menudo llamado el subproceso principal, pero puede crear subprocesos adicionales desde cualquiera de sus subprocesos.

Hilo
Un hilo es una entidad dentro de un proceso que se puede programar para su ejecución. Todos los hilos de un proceso comparten su espacio de direcciones virtuales y los recursos del sistema. Además, cada subproceso mantiene controladores de excepciones, una prioridad de programación, un almacenamiento local de subprocesos, un identificador único de subprocesos y un conjunto de estructuras que el sistema utilizará para guardar el contexto del subproceso hasta que esté programado. El contexto del subproceso incluye el conjunto de registros de la máquina del subproceso, la pila del núcleo, un bloque de entorno de subproceso y una pila de usuario en el espacio de direcciones del proceso del subproceso. Los subprocesos también pueden tener su propio contexto de seguridad, que se puede usar para hacerse pasar por clientes.

Encontré esto en MSDN aquí:
Acerca de los procesos y subprocesos

Microsoft Windows admite la multitarea preventiva, lo que crea el efecto de la ejecución simultánea de varios subprocesos de varios procesos. En una computadora multiprocesador, el sistema puede ejecutar simultáneamente tantos subprocesos como procesadores en la computadora.

Process:

Una instancia en ejecución de un programa se llama proceso.
Algunos sistemas operativos usan el término & # 8216; tarea & # 8216; para referirse a un programa que se está ejecutando.
Un proceso siempre se almacena en la memoria principal, también denominado memoria primaria o memoria de acceso aleatorio.
Por lo tanto, un proceso se denomina como una entidad activa. Desaparece si la máquina se reinicia.
Varios procesos pueden estar asociados con un mismo programa.
En un sistema multiprocesador, se pueden ejecutar múltiples procesos en paralelo.
En un sistema de uni procesador, aunque no se logra un verdadero paralelismo, se aplica un algoritmo de programación de procesos y el procesador está programado para ejecutar cada proceso uno a la vez, lo que produce una ilusión de concurrencia.
Ejemplo: ejecutando varias instancias de la & # 8216; Calculadora & # 8217; programa. Cada una de las instancias se denomina proceso.

Tema :

Un hilo es un subconjunto del proceso.
Se denomina & # 8216; proceso liviano & # 8217 ;, ya que es similar a un proceso real pero se ejecuta dentro del contexto de un proceso y comparte los mismos recursos asignados al proceso por el núcleo.
Generalmente, un proceso tiene solo un hilo de control & # 8211; un conjunto de instrucciones de máquina que se ejecutan a la vez.
Un proceso también puede estar compuesto por varios subprocesos de ejecución que ejecutan instrucciones simultáneamente.
Varios subprocesos de control pueden explotar el verdadero paralelismo posible en sistemas multiprocesador.
En un sistema de uni procesador, se aplica un algoritmo de programación de subprocesos y el procesador está programado para ejecutar cada subproceso uno por uno.
Todos los subprocesos que se ejecutan dentro de un proceso comparten el mismo espacio de direcciones, descriptores de archivos, pila y otros atributos relacionados con el proceso.
Como los hilos de un proceso comparten la misma memoria, la sincronización del acceso a los datos compartidos dentro del proceso adquiere una importancia sin precedentes.

Tomé prestada la información anterior de Knowledge Quest! blog .

Primero, veamos el aspecto teórico. Debe comprender qué es un proceso conceptualmente para comprender la diferencia entre un proceso y un subproceso y lo que se comparte entre ellos.

Tenemos lo siguiente de la sección 2.2.2 El modelo de subprocesos clásico en Modern Operating Systems 3e por Tanenbaum:

El modelo de proceso se basa en dos conceptos independientes: recurso Agrupación y ejecución. A veces es útil separarlos; aquí es donde entran los hilos ...

Continúa:

Una forma de ver un proceso es que es una forma de Grupo de recursos relacionados juntos. Un proceso tiene un espacio de direcciones. Contiene texto y datos del programa, así como otros recursos. Estas El recurso puede incluir archivos abiertos, procesos secundarios, alarmas pendientes, manejadores de señales, información contable, y más. Poniéndolos Juntos, en forma de un proceso, se pueden gestionar más fácilmente. El otro concepto que tiene un proceso es un hilo de ejecución, generalmente acortado a sólo hilo. El hilo tiene un contador de programa que mantiene Seguimiento de qué instrucción ejecutar a continuación. Tiene registros, que Mantener sus variables de trabajo actuales. Tiene una pila, que contiene el Historial de ejecución, con un marco para cada procedimiento llamado pero no sin embargo, regresó de. Aunque un hilo debe ejecutarse en algún proceso, el El hilo y su proceso son conceptos diferentes y pueden ser tratados. por separado Los procesos se utilizan para agrupar los recursos; trapos son las entidades programadas para su ejecución en la CPU.

Más abajo, proporciona la siguiente tabla:

Per process items             | Per thread items
------------------------------|-----------------
Address space                 | Program counter
Global variables              | Registers
Open files                    | Stack
Child processes               | State
Pending alarms                |
Signals and signal handlers   |
Accounting information        |

Tratemos el problema multihilo de hardware . Clásicamente, una CPU admitiría un solo subproceso de ejecución, manteniendo el estado del subproceso a través de un único contador de programa y un conjunto de registros. Pero, ¿qué pasa si hay una falta de caché? Se tarda mucho tiempo en recuperar los datos de la memoria principal, y mientras eso sucede, la CPU simplemente permanece inactiva. Así que alguien tuvo la idea de tener básicamente dos conjuntos de estados de subprocesos (PC + registros) para que otro subproceso (tal vez en el mismo proceso, tal vez en un proceso diferente) pueda trabajar mientras el otro subproceso está esperando en la memoria principal. Hay varios nombres e implementaciones de este concepto, como HyperThreading y Multithreading múltiple simultáneo (SMT para abreviar) .

Ahora veamos el lado del software. Básicamente, hay tres formas en que los subprocesos se pueden implementar en el lado del software.

Hilos del espacio de usuario
Kernel Threads
Una combinación de los dos

Todo lo que necesita para implementar subprocesos es la capacidad de guardar el estado de la CPU y mantener varias pilas, lo que en muchos casos se puede hacer en el espacio del usuario. La ventaja de los subprocesos de espacio de usuario es el cambio súper rápido de subprocesos, ya que no tiene que atrapar el kernel y la capacidad de programar sus subprocesos como desee. El mayor inconveniente es la incapacidad de bloquear I / O (lo que bloquearía todo el proceso y todos los subprocesos de usuario), que es una de las grandes razones por las que usamos subprocesos en primer lugar. El bloqueo de E / S mediante subprocesos simplifica enormemente el diseño del programa en muchos casos.

Los subprocesos del kernel tienen la ventaja de poder utilizar el bloqueo de E / S, además de dejar todos los problemas de programación en el SO. Pero cada cambio de hilo requiere una captura en el kernel que es potencialmente relativamente lento. Sin embargo, si está cambiando hilos debido a una E / S bloqueada, esto no es realmente un problema, ya que la operación de E / S probablemente ya lo atrapó en el kernel.

Otro enfoque es combinar los dos, con varios subprocesos del kernel cada uno con múltiples subprocesos de usuario.

Entonces, volviendo a su pregunta de terminología, puede ver que un proceso y un hilo de ejecución son dos conceptos diferentes y su elección de qué término usar depende de lo que esté hablando. Con respecto al término "proceso de peso ligero", no veo personalmente el punto en él, ya que realmente no transmite lo que está sucediendo, así como el término "hilo de ejecución".

Para explicar más con respecto a la programación concurrente

Un proceso tiene un entorno de ejecución autónomo. Un proceso generalmente tiene un conjunto completo y privado de recursos básicos de tiempo de ejecución; en particular, cada proceso tiene su propio espacio de memoria.
Los subprocesos existen dentro de un proceso & # 8212; Cada proceso tiene al menos uno. Los hilos comparten los recursos del proceso, incluida la memoria y los archivos abiertos. Esto facilita una comunicación eficiente, pero potencialmente problemática.

Teniendo en cuenta a la persona promedio,

En su computadora, abra Microsoft Word y el navegador web. Llamamos a estos dos procesos .

En Microsoft Word, escribe algo y se guarda automáticamente. Ahora, habría observado que la edición y el guardado se realizan en paralelo: la edición en un subproceso y el guardado en el otro subproceso.

Una aplicación consta de uno o más procesos. Un proceso, en los términos más simples, es un programa en ejecución. Uno o más hilos se ejecutan en el contexto del proceso. Una hebra es la unidad básica a la que el sistema operativo asigna el tiempo de procesador. Un subproceso puede ejecutar cualquier parte del código de proceso, incluidas las partes que se están ejecutando actualmente por otro subproceso. Una fibra es una unidad de ejecución que debe ser programada manualmente por la aplicación. Las fibras se ejecutan en el contexto de los hilos que las programan.

Robado de aquí .

Un proceso es una colección de código, memoria, datos y otros recursos. Un hilo es una secuencia de código que se ejecuta dentro del alcance del proceso. Por lo general, puede tener varios subprocesos ejecutándose simultáneamente dentro del mismo proceso.

Cada proceso es un hilo (hilo primario).
Pero cada hilo no es un proceso. Es una parte (entidad) de un proceso.

Ejemplo del mundo real para proceso y subproceso Esto te dará la idea básica sobre el tema y el proceso

Tomé prestada la información anterior de la Respuesta de Scott Langham - gracias

Proceso:

El proceso es un proceso de gran peso.
El proceso es un programa separado que tiene memoria, datos, recursos, etc. separados.
El proceso se crea utilizando el método fork ().
El cambio de contexto entre el proceso requiere mucho tiempo.

Ejemplo:
Digamos, abriendo cualquier navegador (mozilla, Chrome, IE). En este punto, un nuevo proceso comenzará a ejecutarse.

Temas:

Los subprocesos son procesos ligeros. Los subprocesos se incluyen dentro del proceso.
Los hilos tienen una memoria compartida, datos, recursos, archivos, etc.
Los subprocesos se crean utilizando el método clone ().
El cambio de contexto entre los subprocesos no consume mucho tiempo como Proceso.

Ejemplo:
Abriendo múltiples pestañas en el navegador.

Tanto los subprocesos como los procesos son unidades atómicas de la asignación de recursos del sistema operativo (es decir, hay un modelo de concurrencia que describe cómo se divide el tiempo de CPU entre ellos y el modelo de poseer otros recursos del sistema operativo). Hay una diferencia en:

Los recursos compartidos (los subprocesos comparten memoria por definición, no poseen nada, excepto la pila y las variables locales; los procesos también pueden compartir memoria, pero hay un mecanismo separado para eso, mantenido por el sistema operativo)
Espacio de asignación (espacio de kernel para procesos frente a espacio de usuario para subprocesos)

Greg Hewgill anteriormente tenía razón sobre el significado de Erlang de la palabra "proceso", y aquí hay una discusión de por qué Erlang podría hacer procesos ligeros.

Proceso

Es un programa en ejecución. tiene una sección de texto, es decir, el código del programa, la actividad actual representada por el valor del contador del programa & amp; Contenido del registro de procesadores. También incluye la pila de procesos que contiene datos temporales (como parámetros de función, variables direccionadas y de retorno) y una sección de datos, que contiene variables globales. Un proceso también puede incluir un montón, que es la memoria que se asigna dinámicamente durante el tiempo de ejecución del proceso.

Hilo

Un hilo es una unidad básica de utilización de CPU; comprende un ID de hilo, un contador de programa, un conjunto de registros y una pila. compartió con otros subprocesos que pertenecen al mismo proceso su sección de código, sección de datos y otros recursos del sistema operativo, como archivos abiertos y señales.

- Tomado del sistema operativo por Galvin

Intentando responder a esta pregunta relacionada con el mundo Java.

Un proceso es una ejecución de un programa, pero un subproceso es una secuencia de ejecución única dentro del proceso. Un proceso puede contener múltiples hilos. Un hilo a veces se denomina proceso ligero .

Por ejemplo:

Ejemplo 1: Una JVM se ejecuta en un solo proceso y los subprocesos de una JVM comparten el montón que pertenece a ese proceso. Es por eso que varios hilos pueden acceder al mismo objeto. Los hilos comparten el montón y tienen su propio espacio de pila. Así es como la invocación de un subproceso de un método y sus variables locales se mantienen a salvo de otros subprocesos. Pero el montón no es seguro para subprocesos y debe estar sincronizado para la seguridad de subprocesos.

Ejemplo 2: Es posible que un programa no pueda dibujar imágenes leyendo las pulsaciones de tecla. El programa debe prestar toda su atención a la entrada del teclado y, al carecer de la capacidad de manejar más de un evento a la vez, se producirán problemas. La solución ideal para este problema es la ejecución perfecta de dos o más secciones de un programa al mismo tiempo. Los hilos nos permiten hacer esto. Aquí, la imagen de dibujo es un proceso y la lectura de teclas es un subproceso (subproceso).

¿Diferencia entre el hilo y el proceso?

Un proceso es una instancia en ejecución de una aplicación y Un subproceso es una ruta de ejecución dentro de un proceso. Además, un proceso puede contener varios subprocesos. Es importante tener en cuenta que un subproceso puede hacer cualquier cosa que un proceso pueda hacer. Pero como un proceso puede constar de varios subprocesos, un subproceso podría considerarse un proceso "liviano". Por lo tanto, la diferencia esencial entre un subproceso y un proceso es el trabajo que cada uno debe realizar. Los hilos se usan para tareas pequeñas, mientras que los procesos se usan para tareas más pesadas, básicamente la ejecución de aplicaciones.

Otra diferencia entre un subproceso y un proceso es que los subprocesos dentro del mismo proceso comparten el mismo espacio de direcciones, mientras que los diferentes procesos no lo hacen. Esto permite que los subprocesos lean y escriban en las mismas estructuras de datos y variables, y también facilita la comunicación entre los subprocesos. La comunicación entre procesos, también conocida como IPC, o comunicación entre procesos, es bastante difícil y requiere muchos recursos.

Aquí hay un resumen de las diferencias entre subprocesos y procesos:

Los subprocesos son más fáciles de crear que los procesos, ya que no requiere un espacio de direcciones separado.
El multiproceso requiere una programación cuidadosa ya que los subprocesos compartir estructuras de datos que solo deben ser modificadas por un hilo a la vez A diferencia de los hilos, los procesos no comparten lo mismo. espacio de direcciones.
Los hilos se consideran ligeros porque usan mucho menos recursos que procesos.
Los procesos son independientes entre sí. Hilos, ya que compartir el mismo espacio de direcciones son interdependientes, así que cuidado deben tomarse para que diferentes hilos no se pisen unos a otros.
Esta es realmente otra forma de afirmar # 2 arriba.
Un proceso puede constar de varios subprocesos.

http://lkml.iu.edu/hypermail/linux/kernel/9608/0191.html

Linus Torvalds (torvalds@cs.helsinki.fi)

Tue, 6 Aug 1996 12:47:31 +0300 (EET DST)

Messages sorted by: [ date ][ thread ][ subject ][ author ]

Next message: Bernd P. Ziller: "Re: Oops in get_hash_table"

Previous message: Linus Torvalds: "Re: I/O request ordering"

On Mon, 5 Aug 1996, Peter P. Eiserloh wrote:

We need to keep a clear the concept of threads. Too many people seem to confuse a thread with a process. The following discussion does not reflect the current state of linux, but rather is an attempt to stay at a high level discussion.

NO!

There is NO reason to think that "threads" and "processes" are separate entities. That's how it's traditionally done, but I personally think it's a major mistake to think that way. The only reason to think that way is historical baggage.

Both threads and processes are really just one thing: a "context of execution". Trying to artificially distinguish different cases is just self-limiting.

A "context of execution", hereby called COE, is just the conglomerate of all the state of that COE. That state includes things like CPU state (registers etc), MMU state (page mappings), permission state (uid, gid) and various "communication states" (open files, signal handlers etc). Traditionally, the difference between a "thread" and a "process" has been mainly that a threads has CPU state (+ possibly some other minimal state), while all the other context comes from the process. However, that's just one way of dividing up the total state of the COE, and there is nothing that says that it's the right way to do it. Limiting yourself to that kind of image is just plain stupid.

The way Linux thinks about this (and the way I want things to work) is that there is no such thing as a "process" or a "thread". There is only the totality of the COE (called "task" by Linux). Different COE's can share parts of their context with each other, and one subset of that sharing is the traditional "thread"/"process" setup, but that should really be seen as ONLY a subset (it's an important subset, but that importance comes not from design, but from standards: we obviusly want to run standards-conforming threads programs on top of Linux too).

In short: do NOT design around the thread/process way of thinking. The kernel should be designed around the COE way of thinking, and then the pthreads library can export the limited pthreads interface to users who want to use that way of looking at COE's.

Just as an example of what becomes possible when you think COE as opposed to thread/process:

You can do a external "cd" program, something that is traditionally impossible in UNIX and/or process/thread (silly example, but the idea is that you can have these kinds of "modules" that aren't limited to the traditional UNIX/threads setup). Do a:

clone(CLONE_VM|CLONE_FS);

child: execve("external-cd");

/* the "execve()" will disassociate the VM, so the only reason we used CLONE_VM was to make the act of cloning faster */

You can do "vfork()" naturally (it meeds minimal kernel support, but that support fits the CUA way of thinking perfectly):

clone(CLONE_VM);

child: continue to run, eventually execve()

mother: wait for execve

you can do external "IO deamons":

clone(CLONE_FILES);

child: open file descriptors etc

mother: use the fd's the child opened and vv.

All of the above work because you aren't tied to the thread/process way of thinking. Think of a web server for example, where the CGI scripts are done as "threads of execution". You can't do that with traditional threads, because traditional threads always have to share the whole address space, so you'd have to link in everything you ever wanted to do in the web server itself (a "thread" can't run another executable).

Thinking of this as a "context of execution" problem instead, your tasks can now chose to execute external programs (= separate the address space from the parent) etc if they want to, or they can for example share everything with the parent except for the file descriptors (so that the sub-"threads" can open lots of files without the parent needing to worry about them: they close automatically when the sub-"thread" exits, and it doesn't use up fd's in the parent).

Think of a threaded "inetd", for example. You want low overhead fork+exec, so with the Linux way you can instead of using a "fork()" you write a multi-threaded inetd where each thread is created with just CLONE_VM (share address space, but don't share file descriptors etc). Then the child can execve if it was a external service (rlogind, for example), or maybe it was one of the internal inetd services (echo, timeofday) in which case it just does it's thing and exits.

You can't do that with "thread"/"process".

Linus

From the point of view of an interviewer, there are basically just 3 main things that I want to hear, besides obvious things like a process can have multiple threads:

Threads share same memory space, which means a thread can access memory from other's thread memory. Processes normally can not.
Resources. Resources (memory, handles, sockets, etc) are release at process termination, not thread termination.
Security. A process has a fixed security token. A thread, on the other hand, can impersonate different users/tokens.

If you want more, Scott Langham's response pretty much covers everything. All these are from the perspective of an operating system. Different languages can implement different concepts, like tasks, light-wigh threads and so on, but they are just ways of using threads (of fibers on Windows). There are no hardware and software threads. There are hardware and software exceptions and interrupts, or user-mode and kernel threads.

A thread runs in a shared memory space, but a process runs in a separate memory space
A thread is a light-weight process, but a process is a heavy-weight process.
A thread is a subtype of process.

The following is what I got from one of the articles on The Code Project. I guess it explains everything needed clearly.

A thread is another mechanism for splitting the workload into separate execution streams. A thread is lighter weight than a process. This means, it offers less flexibility than a full blown process, but can be initiated faster because there is less for the Operating System to set up. When a program consists of two or more threads, all the threads share a single memory space. Processes are given separate address spaces. all the threads share a single heap. But each thread is given its own stack.

Basically, a thread is a part of a process without process thread wouldn't able to work.
A thread is lightweight whereas the process is heavyweight.
communication between process requires some Time whereas thread requires less time.
Threads can share the same memory area whereas process lives in separate.

Process: program under execution is known as process

Thread: Thread is a functionality which is executed with the other part of the program based on the concept of "one with other"so thread is a part of process..

Coming from the embedded world, I would like to add that the concept of processes only exists in "big" processors (desktop CPUs, ARM Cortex A-9) that have MMU (memory management unit) , and operating systems that support using MMUs (such as Linux). With small/old processors and microcontrollers and small RTOS operating system (real time operating system), such as freeRTOS, there is no MMU support and thus no processes but only threads.

Threads can access each others memory, and they are scheduled by OS in an interleaved manner so they appear to run in parallel (or with multi-core they really run in parallel).

Processes, on the other hand, live in their private sandbox of virtual memory, provided and guarded by MMU. This is handy because it enables:

keeping buggy process from crashing the entire system.
Maintaining security by making other processes data invisible and unreachable. The actual work inside the process is taken care by one or more threads.

While building an algorithm in Python (interpreted language) that incorporated multi-threading I was surprised to see that execution time was not any better when compared to the sequential algorithm I had previously built. In an effort to understand the reason for this result I did some reading, and believe what I learned offers an interesting context from which to better understand the differences between multi-threading and multi-processes.

Multi-core systems may exercise multiple threads of execution, and so Python should support multi-threading. But Python is not a compiled language and instead is an interpreted language¹. This means that the program must be interpreted in order to run, and the interpreter is not aware of the program before it begins execution. What it does know, however, are the rules of Python and it then dynamically applies those rules. Optimizations in Python must then be principally optimizations of the interpreter itself, and not the code that is to be run. This is in contrast to compiled languages such as C++, and has consequences for multi-threading in Python. Specifically, Python uses the Global Interpreter Lock to manage multi-threading.

On the other hand a compiled language is, well, compiled. The program is processed "entirely", where first it is interpreted according to its syntactical definitions, then mapped to a language agnostic intermediate representation, and finally linked into an executable code. This process allows the code to be highly optimized because it is all available at the time of compilation. The various program interactions and relationships are defined at the time the executable is created and robust decisions about optimization can be made.

In modern environments Python's interpreter must permit multi-threading, and this must both be safe and efficient. This is where the difference between being an interpreted language versus a compiled language enters the picture. The interpreter must not to disturb internally shared data from different threads, while at the same time optimizing the use of processors for computations.

As has been noted in the previous posts both a process and a thread are independent sequential executions with the primary difference being that memory is shared across multiple threads of a process, while processes isolate their memory spaces.

In Python data is protected from simultaneous access by different threads by the Global Interpreter Lock. It requires that in any Python program only one thread can be executed at any time. On the other hand it is possible to run multiple processes since the memory for each process is isolated from any other process, and processes can run on multiple cores.

¹ Donald Knuth has a good explanation of interpretive routines in The Art of Computer Programming: Fundamental Algorithms.

Trying to answer it from Linux Kernel's OS View

A program becomes a process when launched into memory. A process has its own address space meaning having various segments in memory such as .text segement for storing compiled code, .bss for storing uninitialized static or global variables, etc. Each process would have its own program counter and user-spcae stack. Inside kernel, each process would have its own kernel stack (which is separated from user space stack for security issues) and a structure named task_struct which is generally abstracted as the process control block, storing all the information regarding the process such as its priority, state,(and a whole lot of other chunk). A process can have multiple threads of execution.

Coming to threads, they reside inside a process and share the address space of the parent process along with other resources which can be passed during thread creation such as filesystem resources, sharing pending signals, sharing data(variables and instructions) therefore making threads lightweight and hence allowing faster context switching. Inside kernel, each thread has its own kernel stack along with the task_struct structure which defines the thread. Therefore kernel views threads of same process as different entities and are schedulable in themselves. Threads in same process share a common id called as thread group id(tgid), also they have a unique id called as the process id (pid).

For those who are more comfortable with learning by visualizing, here is a handy diagram I created to explain Process and Threads.
I used the information from MSDN - About Processes and Threads

Threads within the same process share the Memory, but each thread has its own stack and registers, and threads store thread-specific data in the heap. Threads never execute independently, so the inter-thread communication is much faster when compared to inter-process communication.

Processes never share the same memory. When a child process creates it duplicates the memory location of the parent process. Process communication is done by using pipe, shared memory, and message parsing. Context switching between threads is very slow.

Best answer

Process:

Process is basically a program in execution. It is an active entity. Some operating systems use the term ‘task‘ to refer to a program that is being executed. A process is always stored in the main memory also termed as the primary memory or random access memory. Therefore, a process is termed as an active entity. It disappears if the machine is rebooted. Several process may be associated with a same program. On a multiprocessor system, multiple processes can be executed in parallel. On a uni-processor system, though true parallelism is not achieved, a process scheduling algorithm is applied and the processor is scheduled to execute each process one at a time yielding an illusion of concurrency. Example: Executing multiple instances of the ‘Calculator’ program. Each of the instances are termed as a process.

Thread:

A thread is a subset of the process. It is termed as a ‘lightweight process’, since it is similar to a real process but executes within the context of a process and shares the same resources allotted to the process by the kernel. Usually, a process has only one thread of control – one set of machine instructions executing at a time. A process may also be made up of multiple threads of execution that execute instructions concurrently. Multiple threads of control can exploit the true parallelism possible on multiprocessor systems. On a uni-processor system, a thread scheduling algorithm is applied and the processor is scheduled to run each thread one at a time. All the threads running within a process share the same address space, file descriptors, stack and other process related attributes. Since the threads of a process share the same memory, synchronizing the access to the shared data withing the process gains unprecedented importance.

ref-https://practice.geeksforgeeks.org/problems/difference-between-process-and-thread

The best answer I've found so far is Michael Kerrisk's 'The Linux Programming Interface':

In modern UNIX implementations, each process can have multiple threads of execution. One way of envisaging threads is as a set of processes that share the same virtual memory, as well as a range of other attributes. Each thread is executing the same program code and shares the same data area and heap. However, each thread has it own stack containing local variables and function call linkage information. [LPI 2.12]

This book is a source of great clarity; Julia Evans mentioned its help in clearing up how Linux groups really work in this article.

They are almost as same... But the key difference is a thread is lightweight and a process is heavy-weight in terms of context switching, work load and so on.

Example 1: A JVM runs in a single process and threads in a JVM share the heap belonging to that process. That is why several threads may access the same object. Threads share the heap and have their own stack space. This is how one thread’s invocation of a method and its local variables are kept thread safe from other threads. But the heap is not thread-safe and must be synchronized for thread safety.

Consider process like a unit of ownership or what resources are needed by a task. A Process can have resources like memory space, specific input/output, specific files, and priority etc.

A thread is a dispatchable unit of execution or in simple words the progress through a sequence of instructions

Licenciado bajo: CC-BY-SA con atribución

No afiliado a StackOverflow