2.4.2 Sincronizacion de Procesos en S.C

(Segun Deitel, 1993) 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 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.

(Segun Deitel, 1993) 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 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).

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.

En programación concurrente, se define como a la porción de código de un programa de

computador el cual accede a un recurso compartido (estructura de datos ó dispositivo) que no debe de ser accedido por mas de un hilo en ejecución (thread). La sección crítica por lo general termina en un tiempo determinado y el hilo, proceso ó tarea solo tendrá que esperar un período determinado de tiempo para entrar. Se necesita de un mecanismo de sincronización en la entrada y salida de la sección crítica para asegurar la utilización exclusiva del recurso, por ejemplo un semáforo.

El acceso concurrente se controla teniendo cuidado de las variables que se modifican dentro y fuera de la sección crítica. La sección crítica se utiliza por lo general cuando un programa multihilo actualiza múltiples variables sin un hilo de ejecución separado que lleve los cambios conflictivos a esos datos. Una situación similar, la sección crítica puede ser utilizada para asegurarse de que un recurso compartido, por ejemplo, una impresora, puede ser accedida por un solo proceso a la vez.

La manera en cómo se implementan las secciones puede variar dependiendo de los diversos sistemas operativos. Sólo un proceso puede estar en una sección crítica a la vez.

Propiedades del acceso exclusivo a secciones críticas:
Como criterios de validez de un mecanismo de sincronización nos referiremos al cumplimiento de las siguientes condiciones enunciadas por Dijkstra para el acceso exclusivo a una sección crítica.

a. Exclusión mutua. No puede haber más de un proceso simultáneamente en la SC.
b. No interbloqueo. Ningún proceso fuera de la SC puede impedir que otro entre a la SC.
c. No inanición. Un proceso no puede esperar por tiempo indefinido para entrar a la SC.
d. Independencia del hardware. No se pueden hacer suposiciones acerca del número de procesadores o de la velocidad relativa de los procesos.

Suposición inicial adicional: las instrucciones del Lenguaje Máquina son atómicas y se ejecutan secuencialmente. Además, existen otros criterios que determinan la calidad del mecanismo y que fundamentalmente se refieren a su rendimiento, como son la productividad(número de operaciones de sincronización por unidad de tiempo que el mecanismo es capaz de soportar) y el tratamiento equitativo entre los procesos (por ejemplo, siguiendo una política FIFO para entrar a la sección crítica).