linux - thread - suma con hilos en c

Linux: hilos y prioridades de programación de procesos (2)

Es cierto que el kernel de Linux (a partir de la versión 2.6.23 y posteriores ) planifica las tareas, que son procesos de subprocesos o (subprocesos).

Además de la respuesta aceptada de paxdiablo, estoy agregando esta para agregar una vista informativa más genérica sobre las diferentes formas de programación de subprocesos.

En general, los subprocesos pueden ser subprocesos de espacio de usuario o subprocesos de espacio de kernel . Los hilos del espacio de usuario generalmente son implementados por una biblioteca. Por lo tanto, kernel no sabe casi nada sobre ellos (el kernel solo conoce el proceso al que pertenecen) y se manejan en el espacio del usuario. Por el contrario, los hilos kernel son implementados por kernel y están completamente manejados por el kernel. Puede tomar una vista genérica de la siguiente imagen.

Como puede ver, la imagen de la izquierda muestra algunos subprocesos de espacio de usuario, donde kernel solo posee información sobre los procesos (los llamados bloques de control de proceso - PCB ). Todos los recursos-información sobre los subprocesos se mantienen dentro del proceso (en una tabla de subprocesos) y manejados por la biblioteca de subprocesos correspondiente en el espacio de usuario. En la imagen de la derecha, puede ver los hilos del kernel, donde tanto la tabla de procesos como la tabla de hilos se guardan en el kernel.

Un ejemplo de hilos del kernel son LinuxThreads , que ahora han sido reemplazados por la biblioteca NPTL más moderna. Un ejemplo de subprocesos de espacio de usuario es la biblioteca GNU Portable Threads

Ahora, en lo que respecta a la programación, como se espera, los hilos del espacio de usuario se programan de una manera diferente a los hilos del kernel:

Cuando se utilizan subprocesos de espacio de usuario, el planificador está programando procesos. Por lo tanto, selecciona un proceso específico y asigna el tiempo cuántico permisible. Luego, el programador de subprocesos dentro del proceso es responsable de seleccionar cómo se realizará la programación entre los subprocesos. Como los hilos del espacio de usuario no son detenidos por las interrupciones, el hilo seleccionado tenderá a consumir todo el quantum del proceso, hasta que haya completado su tarea. Entonces, la programación hipotética en este caso sería algo así como:
P1 (T1), P2 (T1), P1 (T1), P2 (T1 - T1 completa su tarea y rendimientos ), P2 (T2 - para el tiempo restante, P1 (T1), P2 (T2), P1 (T1) ), ...
Cuando se usan subprocesos de kernel, kernel programa subprocesos. El kernel no muestra interés por el proceso al que pertenece el subproceso, pero asigna un quantum de tiempo a cada subproceso por igual. Entonces, en este caso la programación hipotética sería:
P1 (T1), P2 (T1), P2 (T2), P1 (T1), P2 (T2), P1 (T1), ...

Tenga en cuenta que también hay otra categoría, los subprocesos híbridos , donde algunos subprocesos de espacio de usuario se traducen en un subproceso kernel. Sin embargo, es más complejo y requiere un análisis más completo.

si creamos pthreads (pthread_create) o procesos (fork) con políticas de programación predeterminadas en Linux, ¿el planificador tratará los procesos y subprocesos con la misma prioridad mientras los programa?

digamos que hay un proceso P1 con un hilo y un proceso P2 con 2 hilos T1 T2

digamos que solo hay un núcleo ... la programación será P1 T1 P1 T2 P1 T1 P1 T2

P1 T1 T2 P1 T1 T2

Linux ya no programa procesos en absoluto.

Dentro del kernel, los hilos están programados. El concepto de un proceso es ahora una construcción artificial vista principalmente por cosas que están fuera del kernel. Obviamente, el kernel tiene que saber cómo se vinculan los hilos, pero no para fines de programación.

Básicamente, el kernel mantiene una gran cantidad de subprocesos y cada subproceso tiene un líder de grupo de subprocesos, que es lo que se ve en el exterior como el proceso. Un hilo tiene un ID de hilo y un ID de grupo de hilo; se parece mucho a la relación entre un PID y un PPID (ID de proceso e ID de proceso principal).

Cuando creas un hilo normal , el kernel le da un nuevo ID de hilo pero su ID de grupo de hilo se establece idéntica a la ID del grupo del hilo que lo creó. De esta manera, parece un hilo dentro de un proceso para el mundo exterior.

Cuando se bifurca, el núcleo le da una nueva identificación de hilo y establece su ID de grupo de hilo al mismo valor que su ID de hilo. De esta manera, parece un proceso para el mundo exterior.

La mayoría de las utilidades ajenas al kernel que informan sobre los procesos realmente solo están informando sobre subprocesos donde el ID del subproceso es el mismo que el ID del grupo de subprocesos.

Hay sutilezas con otros métodos que probablemente sean demasiado complicados para entrar aquí. Lo que he escrito arriba es (con suerte) un buen tratado de nivel medio.

Ahora, para su pregunta específica, no sería ningún caso ya que P1 solo tiene un hilo (no hay P1T2 ).

Con el kernel, los hilos son P1T1 , P2T1 y P2T2 y, suponiendo que tengan las mismas propiedades de programación y se comporten igual ^(a) , así es como se programarán.

Ver también:

para más información.

^(a) : Obviamente eso cambia si los hilos comienzan a bloquear en E / S (kernel no los programará hasta que E / S esté disponible) o libere sus cuánticos de tiempo temprano (kernel probablemente aumentará su prioridad como recompensa por jugar bien) pero luego no se están comportando igual.