TEMA 2. GESTIÓN DE PROCESOS - Universidad de Almería

Diseño de Sistemas Operativos
Tema 2. Gestión de Procesos
2.7.1.3. Observaciones sobre la Creación de un Proceso (Padre e Hijo).
• Las u-Areas son iguales a excepción del puntero a la Tabla de Procesos. Una vez creado el contexto
estático va por el dinámico. El kernel copia la primera capa (capa 1) que contiene el nivel de
usuario y también la pila del kernel (con la capa de llamada a fork). Si la implementación incluye
pila del kernel en la uArea ya en el punto anterior se hace esta copia (en cualquier caso la pila del
padre e hijo son iguales). Ahora hace una copia falsa en la pila del hijo para simular que se ha
ejecutado antes. En esta capa se debe incluir el contexto de registros de la capa 1.
• Observar que padre e hijo comparten los archivos abiertos antes del fork (los que se abran después
ya van a cuenta de cada proceso), por lo que en el siguiente código ejemplo los dos procesos jamás
leen o escriben en el mismo offset de los archivos descritos por fr y fw. En este caso ambos
procesos compartirán las tablas de archivos cada uno con los valores para fr y fw apuntando a la
misma entrada en la Tabla de Archivos. Aunque de la apariencia que se copia el archivo por dos
veces, lo cierto es que el contenido del archivo destino dependerá de como se planifiquen los
procesos.
2.7.1.4. Clonado en Linux (clone).
• Diferentes libros sobre sistemas operativos definen un proceso de diferentes formas, empezando
por “instancia de un programa en ejecución” y finalizando con “lo que es producido por las
llamadas del sistema fork o clone”. Bajo Linux, hay tres clases de procesos:
− el/los thread(s) vacío(s),
− threads del kernel,
− tareas de usuario.
• El thread vacío es creado en tiempo de compilación para la primera CPU; es entonces creado
“manualmente” para cada CPU por medio de la función específica de la arquitectura
fork_by_hand() en arch/i386/kernel/smpboot.c, el cual desenrolla la llamada al sistema fork a mano
(en algunas arquitecturas). Las tareas vacías comparten una estructura init_task pero tienen una
estructura privada TSS, en la matriz de cada CPU init_tss. Todas las tareas vacías tienen pid = 0 y
ninguna otra tarea puede compartir el pid, esto es, usar el flag CLONE_PID en clone.
• Los threads del kernel son creados usando la función kernel_thread() la cual invoca a la llamada al
sistema clone en modo kernel. Los threads del kernel usualmente no tienen espacio de direcciones
de usuario, esto es p->mm = NULL, porque ellos explícitamente hacen exit_mm(), ej. a través de la
función daemonize(). Los threads del kernel siempre pueden acceder al espacio de direcciones del
kernel directamente. Ellos son asignados a números pid en el rango bajo. Funcionando en el anillo
del procesador 0 (en x86) implica que los threads del núcleo disfrutan de todos los privilegios de
E/S y no pueden ser pre-desocupados por el scheduler o planificador.
• Las tareas de usuario son creadas por medio de las llamadas al sistema clone o fork, las cuales
internamente invocan a kernel/fork.c:do_fork().
• Por tanto Linux, permite crear clones de procesos. Un proceso clon se crea por la llamada la
sistema clone por duplicación de su proceso padre. Pero contrariamente a un proceso hijo clásico,
puede compartir una parte de su contexto con su padre. Según las opciones especificadas en la
llamada al sistema clone, se pueden compartir una o más partes de su contexto:
− El espacio de direccionamiento. Los dos procesos comparten los mismos segmentos de
código y de datos. Toda modificación efectuada por uno es visible por parte del otro.
− Las informaciones de control del sistema de archivos. Los dos procesos comparten los
mismos directorios raíz y actual. Si uno de estos directorios es modificado por uno de los
procesos (por la primitivas chdir y chroot), la modificación es efectiva para el otro.
− Los descriptores de archivos abiertos. Los dos procesos comparten los mismos descriptores
de archivos abiertos. Si uno de ellos cierra un archivo, el otro ya no puede acceder a él.
− Los gestores de señales: los dos procesos comparten la tabla de funciones llamada en la
recepción de una señal. Toda modificación por parte de uno de los procesos (sigaction),
provoca el cambio de la rutina de tratamiento de la señal por el otro proceso.
− El identificador de proceso. Los dos procesos pueden compartir el mismo número de
proceso.
Departamento de Lenguajes y Computación. Universidad de Almería Página 2.32