Programación de subprocesos

La programación de subprocesos implica la programación de dos límites, 
 

  • Programación de subprocesos de nivel de usuario (ULT) a subprocesos de nivel de kernel (KLT) a través de un proceso ligero (LWP) por parte del desarrollador de la aplicación.
  • Programación de subprocesos a nivel de kernel por parte del programador del sistema para realizar diferentes funciones únicas del sistema operativo.

Proceso ligero (LWP): 
los procesos ligeros son subprocesos en el espacio del usuario que actúan como una interfaz para que ULT acceda a los recursos físicos de la CPU. La biblioteca de subprocesos programa qué subproceso de un proceso ejecutar en qué LWP y durante cuánto tiempo. El número de LWP creado por la biblioteca de subprocesos depende del tipo de aplicación. En el caso de una aplicación vinculada a E/S, la cantidad de LWP depende de la cantidad de subprocesos a nivel de usuario. Esto se debe a que cuando un LWP se bloquea en una operación de E/S, para invocar el otro ULT, la biblioteca de subprocesos necesita crear y programar otro LWP. Por lo tanto, en una aplicación vinculada a E/S, el número de LWP es igual al número de ULT. En el caso de una aplicación vinculada a la CPU, depende solo de la aplicación. Cada LWP se adjunta a un subproceso de nivel de kernel independiente. 

En tiempo real, el primer límite de la programación de subprocesos va más allá de especificar la política de programación y la prioridad. Requiere que se especifiquen dos controles para los subprocesos de nivel de usuario: Ámbito de contención y Dominio de asignación. Estos se explican a continuación a continuación. 

1. Alcance de la contención: 
la palabra contención aquí se refiere a la competencia o lucha entre los subprocesos de nivel de usuario para acceder a los recursos del kernel. Por lo tanto, este control define hasta qué punto tiene lugar la contención. Lo define el desarrollador de la aplicación utilizando la biblioteca de subprocesos. Según el alcance de la contención, se clasifica como Ámbito de contención del proceso y Ámbito de contención del sistema

  1. Ámbito de contención del proceso (PCS): 
    la contención tiene lugar entre subprocesos dentro de un mismo proceso . La biblioteca de subprocesos programa el subproceso PCS de alta prioridad para acceder a los recursos a través de los LWP disponibles (prioridad especificada por el desarrollador de la aplicación durante la creación del subproceso). 

     

  2. Ámbito de contención del sistema (SCS): 
    la contención tiene lugar entre todos los subprocesos del sistema . En este caso, cada subproceso SCS está asociado a cada LWP por la biblioteca de subprocesos y el programador del sistema los programa para acceder a los recursos del kernel. 

    En los sistemas operativos LINUX y UNIX, la biblioteca POSIX Pthread proporciona una función Pthread_attr_setscope para definir el tipo de ámbito de contención para un subproceso durante su creación. 
     

int Pthread_attr_setscope(pthread_attr_t *attr, int scope) 
  1. El primer parámetro indica a qué subproceso dentro del proceso se define el alcance. 
    El segundo parámetro define el alcance de la disputa para el subproceso apuntado. Toma dos valores. 
     
PTHREAD_SCOPE_SYSTEM
PTHREAD_SCOPE_PROCESS 
  1. Si el valor de alcance especificado no es compatible con el sistema, la función devuelve ENOTSUP

     

2. Dominio de asignación: 
el dominio de asignación es un conjunto de uno o más recursos por los que compite un subproceso. En un sistema multinúcleo, puede haber uno o más dominios de asignación donde cada uno consta de uno o más núcleos. Un ULT puede ser parte de uno o más dominios de asignación. Debido a esta alta complejidad en el manejo de interfaces arquitectónicas de hardware y software, no se especifica este control. Pero por defecto, el sistema multinúcleo tendrá una interfaz que afecta el dominio de asignación de un hilo. 

Considere un escenario, un sistema operativo con tres procesos P1, P2, P3 y 10 subprocesos de nivel de usuario (T1 a T10) con un solo dominio de asignación. El 100 % de los recursos de la CPU se distribuirá entre los tres procesos. La cantidad de recursos de CPU asignados a cada proceso y a cada subproceso depende del alcance de la contienda, la política de programación y la prioridad de cada subproceso definido por el desarrollador de la aplicación mediante la biblioteca de subprocesos y también depende del programador del sistema. Estos subprocesos de nivel de usuario tienen un ámbito de contención diferente. 

En este caso, la disputa por el dominio de asignación se lleva a cabo de la siguiente manera, 

  1. Proceso P1: 
    Todos los subprocesos PCS T1, T2, T3 del Proceso P1 competirán entre sí. Los subprocesos PCS de un mismo proceso pueden compartir uno o más LWP. T1 y T2 comparten un LWP y T3 se asignan a un LWP separado. Entre T1 y T2, la asignación de recursos del kernel a través de LWP se basa en la programación de prioridad preventiva de la biblioteca de subprocesos. Un subproceso con una prioridad alta se adelantará a los subprocesos de baja prioridad. Mientras que el subproceso T1 del proceso p1 no puede adelantarse al subproceso T3 del proceso p3 incluso si la prioridad de T1 es mayor que la prioridad de T3. Si la prioridad es igual, la asignación de ULT a los LWP disponibles se basa en la política de programación de subprocesos del programador del sistema (no por biblioteca de subprocesos, en este caso). 
     
  2. Proceso P2: 
    Ambos subprocesos SCS T4 y T5 del proceso P2 competirán con los procesos P1 en su conjunto y con los subprocesos SCS T8, T9, T10 del proceso P3. El programador del sistema programará los recursos del núcleo entre los subprocesos P1, T4, T5, T8, T9, T10 y PCS (T6, T7) del proceso P3 considerando cada uno como un proceso separado. Aquí, la biblioteca Thread no tiene control sobre la programación del ULT para los recursos del kernel. 
     
  3. Proceso P3: 
    Combinación de hilos PCS y SCS. Considere si el programador del sistema asigna el 50 % de los recursos de la CPU para procesar P3, entonces el 25 % de los recursos es para subprocesos con alcance de proceso y el 25 % restante para subprocesos con alcance del sistema. Los subprocesos PCS T6 y T7 se asignarán para acceder al 25 % de los recursos en función de la prioridad de la biblioteca de subprocesos. Los subprocesos SCS T8, T9, T10 dividirán el 25 % de los recursos entre ellos y accederán a los recursos del kernel a través de LWP y KLT separados. La programación de SCS es realizada por el programador del sistema. 
     

Nota: 
Para cada llamada al sistema para acceder a los recursos del kernel, el programador del sistema crea un subproceso de nivel de kernel y lo asocia a un LWP separado. 
 

Number of Kernel Level Threads = Total Number of LWP 
Total Number of LWP = Number of LWP for SCS + Number of LWP for PCS
Number of LWP for SCS = Number of SCS threads
Number of LWP for PCS = Depends on application developer 

Aquí, 
 

Number of SCS threads = 5 
Number of LWP for PCS = 3 
Number of SCS threads = 5 
Number of LWP for SCS = 5 
Total Number of LWP   = 8 (=5+3)
Number of Kernel Level Threads = 8 

Ventajas de PCS sobre SCS: 
 

  • Si todos los subprocesos son PCS, entonces el cambio de contexto, la sincronización, la programación, todo se lleva a cabo dentro del espacio de usuario. Esto reduce las llamadas al sistema y logra un mejor rendimiento. 
     
  • PCS es más barato que SCS. 
     
  • Los subprocesos PCS comparten uno o más LWP disponibles. Para cada subproceso SCS, se asocia un LWP independiente. Para cada llamada al sistema, se crea un KLT independiente. 
     
  • La cantidad de KLT y LWP creados depende en gran medida de la cantidad de subprocesos SCS creados. Esto aumenta la complejidad del kernel para manejar la programación y la sincronización. Por lo tanto, da como resultado una limitación sobre la creación de subprocesos SCS, indicando que el número de subprocesos SCS debe ser menor que el número de subprocesos PCS. 
     
  • Si el sistema tiene más de un dominio de asignación, la programación y sincronización de recursos se vuelve más tediosa. Los problemas surgen cuando un subproceso SCS es parte de más de un dominio de asignación, el sistema tiene que manejar un número n de interfaces. 
     

El segundo límite de la programación de subprocesos implica la programación de la CPU por parte del programador del sistema. El programador considera cada subproceso a nivel de kernel como un proceso separado y proporciona acceso a los recursos del kernel. 
 

?list=PLqM7alHXFySEJYFqrpxG4eTbUAiX6jD0Y
 

Publicación traducida automáticamente

Artículo escrito por maha93427 y traducido por Barcelona Geeks. The original can be accessed here. Licence: CCBY-SA

Deja una respuesta

Tu dirección de correo electrónico no será publicada. Los campos obligatorios están marcados con *