Linux modelo multihilo

Un proceso es una actividad de ejecución de un programa en una computadora. Cuando ejecutas un programa, comienzas un proceso. Obviamente, el programa está muerto (estático) y el proceso está vivo (dinámico). Los procesos se pueden dividir en procesos de sistema y procesos de usuario. Los procesos que se utilizan para completar las diversas funciones del sistema operativo
son procesos del sistema, que son el propio sistema operativo en el estado de ejecución, el proceso del usuario son todos los procesos iniciados por usted. Un proceso es una unidad en la que un sistema operativo asigna recursos. En Windows
, el proceso se refina aún más en subprocesos, es decir, hay varias unidades más pequeñas que pueden ejecutarse de forma independiente en un solo proceso. He visto muchos artículos sobre procesos y subprocesos de Linux. Creo que se puede decir que es el más clásico ------------------------------ --- I. Conocimientos básicos: hilos y procesos De acuerdo con la definición en el libro de texto, el proceso es la unidad más pequeña de administración de recursos, y el hilo es la unidad más pequeña de ejecución del programa. En el diseño del sistema operativo, la evolución del subproceso desde el proceso, el objetivo principal es brindar un mejor soporte a SMP y reducir la sobrecarga de conmutación de contexto (proceso /subproceso). Independientemente de la división, un proceso necesita al menos un subproceso como su ejecución de instrucciones. El proceso administra recursos (como cpu, memoria, archivos, etc.) y asigna subprocesos a una determinada CPU. Por supuesto, un proceso puede tener varios subprocesos. En este punto, si el proceso se está ejecutando en una máquina SMP, puede usar múltiples CPU para ejecutar cada subproceso al mismo tiempo, logrando un paralelismo máximo para mejorar la eficiencia, al mismo tiempo, incluso en una sola CPU. En la máquina, el modelo de subprocesos múltiples se usa para diseñar el programa. Al igual que el modelo de multiproceso se usa en lugar del modelo de proceso único, el diseño es más conciso, la función es más completa y la eficiencia de ejecución del programa es mayor. Por ejemplo, se utilizan varios subprocesos para responder a múltiples entradas. En este momento, la función implementada por el modelo de subprocesos múltiples puede implementarse realmente mediante el modelo de multiproceso. Comparado con este último, la sobrecarga de conmutación de subprocesos es mucho menor que el proceso. Semánticamente, la respuesta es más que simultánea. Al ingresar a dicha función, en realidad se comparten todos los recursos excepto cpu. De acuerdo con los dos significados principales del modelo de subproceso, se desarrollan respectivamente dos modelos de subproceso de subproceso de núcleo y de usuario. El estándar de clasificación es principalmente si el programador de hilos está en el núcleo o fuera del núcleo. El primero es más propicio para el uso concurrente de recursos de multiprocesador, mientras que el segundo está más preocupado por la sobrecarga de cambio de contexto. En el sistema comercial actual, los dos se usan generalmente en combinación, lo que proporciona el subproceso central para satisfacer las necesidades del sistema smp, y también admite otro mecanismo de subproceso en el estado del usuario mediante el uso de la biblioteca de subprocesos. En este momento, un subproceso central simultáneamente Conviértete en un programador para múltiples hilos en modo de usuario. Al igual que con muchas tecnologías, "híbrido" generalmente conduce a una mayor eficiencia, pero también conlleva una mayor dificultad de implementación. Debido al diseño simple y simple, Linux no se ha mezclado desde el principio. El plan del modelo, pero utiliza otra idea de "mezcla" en su implementación. En la implementación específica del mecanismo de subprocesos, el subproceso se puede implementar en el kernel del sistema operativo, o se puede implementar fuera del núcleo. Este último obviamente requiere que al menos el proceso se implemente en el núcleo, mientras que el primero generalmente requiere que el proceso también sea compatible con el núcleo. El modelo de subprocesos a nivel de núcleo obviamente requiere el soporte del primero, mientras que el modelo de subprocesos a nivel de usuario no se basa necesariamente en el último. Esta diferencia, como se mencionó anteriormente, se debe a los diferentes estándares de los dos métodos de clasificación. Cuando tanto el proceso de soporte como el subproceso son compatibles con el kernel, el proceso de subproceso "muchos a muchos" se puede implementar, es decir, un cierto subproceso de un proceso está programado por el kernel y, al mismo tiempo, también se puede utilizar como un grupo de subprocesos de nivel de usuario. El programador elige el subproceso de nivel de usuario adecuado para ejecutarse en su espacio. Este es el modelo de subprocesos "híbrido" mencionado anteriormente que satisface las necesidades de los sistemas multiprocesador y minimiza la sobrecarga de programación. La mayoría de los sistemas operativos comerciales (como Digital Unix, Solaris e Irix) utilizan este modelo de subprocesamiento que implementa completamente el estándar POSIX 1003.1c. Los hilos implementados fuera del kernel se pueden dividir en dos modelos: "uno a uno", "muchos a uno", el primero utiliza un proceso central (quizás un proceso liviano) para un hilo, y la programación de hilos es equivalente a La programación del proceso se transfiere al núcleo, mientras que la última es multihebra completamente fuera del núcleo, y la programación se realiza en modo de usuario. Esta última es la implementación del simple modelo de subprocesos a nivel de usuario mencionado anteriormente. Obviamente, este programador de subprocesos extra-core en realidad solo necesita completar el cambio de la pila de ejecución de subprocesos. La sobrecarga de programación es muy pequeña, pero al mismo tiempo debido a la señal del núcleo (independientemente de Si es síncrono o asíncrono) se basa en procesos y, por lo tanto, no se puede ubicar en subprocesos, por lo que esta implementación no se puede usar en sistemas multiprocesador, y este requisito es cada vez más grande, por lo que en realidad La implementación de subprocesos puros a nivel de usuario casi ha desaparecido, excepto con el propósito de la investigación de algoritmos. El kernel de Linux solo proporciona soporte para procesos ligeros, lo que limita la implementación de un modelo de subprocesos más eficiente, pero Linux se enfoca en optimizar la sobrecarga de programación del proceso y, hasta cierto punto, compensa esta falla. En la actualidad, el mecanismo de subprocesamiento más popular, LinuxThreads, adopta el proceso de subproceso "uno a uno", que se entrega al núcleo, e implementa un mecanismo de administración de subprocesos que incluye el procesamiento de señales a nivel de usuario. El mecanismo operativo de Linux-LinuxThreads es el enfoque de este artículo. En segundo lugar, la implementación del proceso ligero en el kernel 2.4 de Linux La definición del proceso inicial consta de tres partes: programa, recurso y su ejecución. El programa generalmente se refiere al código. El recurso generalmente incluye recursos de memoria, recursos de E /S, procesamiento de señales, etc. a nivel del sistema operativo. La ejecución de un programa generalmente se entiende como el contexto de ejecución, incluida la ocupación de la CPU, y luego se convierte en un subproceso. Antes de que surgiera el concepto de subproceso, para reducir la sobrecarga de la conmutación de procesos, el diseñador del sistema operativo revisó gradualmente el concepto del proceso, permitiendo gradualmente que los recursos ocupados por el proceso se eliminaran de su cuerpo principal, permitiendo que algunos procesos compartan una parte de los recursos, como archivos y señales. , memoria de datos, e incluso código, que desarrolla el concepto de procesos ligeros. El kernel de Linux ha implementado un proceso liviano en la versión 2.0.x. La aplicación puede especificar un proceso liviano o un proceso normal con un parámetro diferente a través de una interfaz unificada de llamadas al sistema clone (). En el kernel, la llamada clone () llamará a do_fork () después de pasar el parámetro y la interpretación. Esta función del kernel es también la implementación final de las llamadas del sistema fork () y vfork (): < linux-2.4.20 /kernel /fork .c > int do_fork (clone_flags largo sin firmar, stack_start largo sin firmar, struct pt_regs * regs, stack_size largo sin signo) donde clone_flags se toma de los siguientes valores de macro /quot;, lt; linux-2.4.20 /include /linux /Sched.h > #define CSIGNAL 0x000000ff /* la máscara de señal se enviará en la salida * /#define CLONE_VM 0x00000100 /* establecer si VM se comparte entre procesos * /#define CLONE_FS 0x00000200 /* establecer si fs información compartida entre procesos * /#define CLONE_FILES 0x00000400 /* establecer si los archivos abiertos se comparten entre procesos * /#define CLONE_SIGHAND 0x00000800 /* establecer si los manejadores de señales y las señales bloqueadas se comparten * /#define CLONE_PID 0x00001000 /* establecer si se compartió pid * /