Descargar

Sincronización entre procesos


Partes: 1, 2, 3

    1. Representación de los procesos
    2. Hilos de ejecución o thread
    3. Sincronización y comunicación entre procesos
    4. Sección crítica
    5. Modelo de sincronización mutex (mutual exclusión object) exclusión mutua
    6. Modelo de sincronización por semáforos
    7. Modelo de sincronización por mensajes
    8. Problemas de sincronización
    9. Los clásicos problemas de la sincronización de procesos
    10. Interbloqueo
    11. Recursos reutilizables
    12. Recursos consumibles
    13. Bibliografía

    INTRODUCCIÓN

    En los sistemas operativos multiprogramados surge el concepto de proceso, asociado a la ejecución de un programa. En general, un proceso es un flujo de ejecución, representado básicamente por un contador de programa, y su contexto de ejecución, que puede ser más o menos amplio. Así, un proceso incluye en su contexto el estado de la pila, el estado de la memoria y el estado de la E/S, mientras que un thread típico tiene como contexto propio poco más que la pila. En algunos sistemas es posible determinar el contexto propio de un proceso en el momento de su creación, como ocurre con la llamada al sistema clone() de Linux. En adelante, sin perder generalidad, utilizaremos siempre el término proceso, independientemente de cuál sea su contexto.

    Uno de los objetivos del sistema operativo es la representación de los procesos y el soporte de los cambios de contexto entre procesos, que posibilitan la compartición del recurso CPU. El acceso a otros recursos compartidos y la comunicación entre procesos relacionados (por ejemplo, de una misma aplicación) hacen necesaria la utilización de mecanismos de sincronización dentro del sistema operativo. Típicamente, un proceso requiere la CPU durante un periodo de tiempo, realiza alguna operación de E/S, y vuelve a requerir la CPU, repitiéndose este ciclo hasta la finalización del programa. El proceso pasa por diversos estados entre los que se definen transiciones, como representa, en su forma más sencilla, el grafo de la Figura siguiente.

    Cada vez que un proceso pasa al estado preparado, está compitiendo por el recurso CPU. Un segundo objetivo del sistema operativo multiprogramado es la planificación del uso del (de los) recurso(s) de proceso. Los criterios que se siguen para la planificación y las políticas que se usan se estudiarán mas adelante en el desarrollo de la presente investigación.

    Para realizar el estudio de dichas políticas se realiza una sintetizada referencia a la representación de los procesos, para luego definir hilos de ejecución o threads, estableciendo diferencias entre procesos y hilos de ejecución, sus ventajas desventajas, estados, sincronización y tipos, para luego empezar a estudiar el fenómeno de la sincronización de procesos, estableciendo su definición y características, se esboza la definición, modelo, propiedades de la sección critica, así como la descripción detallada de algunos de los principales modelos de sincronización tales como el de exclusión mutua (mutex), semáforos y mensajes, para después describir los diferentes problemas de sincronización tales como; el fumador de cigarrillos, la panadería de Lamport, los filósofos que cenan (sabios), el barbero dormilón, lectores y escritores, y productor consumidor y finalmente se estudia el interbloqueo estableciendo su definición, características, condiciones necesarias y suficientes para su existencia, en cuanto a su detección y recuperación.

    Representación de los procesos

    Para representar los procesos, un sistema operativo multiprogramado debe almacenar información en base a la cual:

    Identificar cada proceso. Se utiliza un identificador del proceso, que suele ser un entero.

    Representar el estado de cada proceso para mantener el grafo de transición de estados. Normalmente los estados se representan mediante colas de procesos.

    Planificar el siguiente proceso que entre en la CPU (scheduling). Se requiere información que permita aplicar los criterios de planificación (prioridad, quantum, etc).

    Contabilizar el uso de recursos por el proceso (tiempo consumido de CPU, tiempo de ejecución del proceso, tiempos máximos asignados, identificador de usuario). Parte de esta información puede ser útil para la planificación.

    Gestionar el contexto de los procesos. Por cada proceso hay que almacenar el estado del procesador, de la pila y de los otros recursos (memoria y entrada/salida). En un cambio de contexto hay que guardar el contexto del proceso que abandona la ejecución y restaurar el contexto del proceso planificado.

    Gestionar la memoria. Punteros a tablas de páginas y otra información de la que hablaremos en su momento.

    Soportar la entrada/salida. Peticiones pendientes, dispositivos asignados, tabla de canales, etc.

    Esta información no tiene por qué estar concentrada en una estructura de datos única para cada proceso. Cómo se almacene dependerá de la estructura del sistema operativo. Por ejemplo, en los sistemas por capas, la información de un proceso estará segmentada a través de las capas. Sin embargo, conceptualmente podemos suponer una estructura, que denominaremos Bloque de Control del Proceso o PCB (Process Control Block), que almacena la información del proceso. Los PCBs se enlazan para formar listas encadenadas (Figura B), por lo que el PCB incluye uno o más apuntadores. La disciplina de acceso a los PCBs puede ser diversa (FCFS, en base a la prioridad, etc). Así, la gestión de procesos en el sistema operativo se puede representar mediante un conjunto de colas de PCBs. Habrá una cola para los procesos que estén en estado preparado para ejecución, una cola para cada condición de bloqueo, e incluso, para generalizar, se puede considerar una cola de procesos en ejecución (por cada CPU).

    Figura B Una lista de PCBs de encadenado simple

    De esta forma, podemos definir el sistema operativo como un modelo de procesos que se representa mediante un sistema de colas, según se muestra a continuación.

    Partes: 1, 2, 3
    Página siguiente