Proceso: –

En un sistema multiprogramado o de tiempo compartido, un proceso es la imagen en memoria de un programa, junto con la información relacionada con el estado de su ejecución. –Un programa en ejecución. –Una instancia de un programa ejecutándose en un computador.  –La entidad que se puede asignar o ejecutar en un procesador. –Una unidad de actividad caracterizada por un solo hilo secuencial de ejecución, un estado actual, y un conjunto de recursos del sistema asociados. 

Diferencia entre programa y proceso

Un programa es una entidad pasiva, una lista de instrucciones; un proceso es una entidad activa, que –empleando al programa– define la actuación que tendrá el sistema. 

Imagen de un proceso: Foto:

[Identificador del proceso, información del estado del procesador, información de control del proceso (BCP), pila de usuario, espacio privado de direcciones de usuario (Programa y datos), pila de núcleo, espacio compartido de direcciones.] 

Datos del usuario:

La parte modificable del espacio de usuario. Puede incluir datos de programa, área de pila de usuario, y programas que puedan ser modificados. -Programa de usuario:
El programa a ejecutar. –

Pila de sistema:

Cada proceso tiene una o más pilas de sistema (LIFO) asociadas a él. Una pila se utiliza para almacenar los parámetros y las direcciones de retorno de los procedimientos y llamadas a sistema. –

Bloque de control de proceso:

Datos necesarios para que el sistema operativo pueda controlar los procesos. —

PCB (Process Control Block)

La información que debe manipular el sistema operativo relativa a cada uno de los procesos actuales se suele almacenar en una estructura llamada bloque de control de proceso (PCB – Process Control Block).  

Atributos del PCB –

Estado del proceso:

El estado actual del proceso. –

Contador de programa:

Cual es la siguiente instrucción a ser ejecutada por el proceso. –

Registros del CPU:

La información específica del estado del CPU mientras el proceso está en ejecución (debe ser respaldada y restaurada cuando se registra un cambio de estado). –

Información de planificación (scheduling):

La prioridad del proceso, la cola en que está agendado, y demás información que puede ayudar al sistema operativo a planificar los procesos. –  Información de administración de memoria
: La información de mapeo de memoria (páginas o segmentos, dependiendo del sistema operativo), incluyendo la pila (stack) de llamadas. –

Información de contabilidad:

Información de la utilización de recursos que ha tenido este proceso—Puede incluir el tiempo total empleado y otros (de usuario, cuando el procesador va avanzando sobre las instrucciones del programa propiamente, de sistema cuando el sistema operativo está atendiendo las solicitudes del proceso), uso acumulado de memoria y dispositivos, etc.

Estado de E/S:

Listado de dispositivos y archivos asignados que el proceso tiene abiertos en un momento dado.  

Atributos de los procesos dentro del PCB –

Identificador de proceso:

en prácticamente todos los sistemas operativos, a cada proceso se le asocia un identificador numérico único, que puede ser simplemente un índice en la tabla de procesos principal. Cuando los procesos pueden crear otros procesos, los identificadores indican el proceso padre y los descendientes en cada caso. Junto con estos identificadores de proceso, a un proceso se le puede asignar un identificador de usuario que indica qué usuario es responsable del trabajo. –

Información de estado de proceso:

indica los contenidos de los registros del procesador. Normalmente, el conjunto de registros incluye registros visibles por usuario, registros de control y de estado, y punteros de pila. –

Información de control de proceso

Esta información adicional la necesita el sistema operativo para controlar y coordinar varios procesos activos. —

Modos de ejecución

Muchos procesadores proporcionan al menos dos modos de ejecución. Ciertas instrucciones se pueden ejecutar en modos privilegiados únicamente. Éstas incluirían lectura y modificación de los registros de control, por ejemplo la palabra de estado de programa; instrucciones de E/S primitivas; e instrucciones relacionadas con la gestión de memoria. Adicionalmente, ciertas regiones de memoria sólo se pueden acceder en los modos más privilegiados. El modo menos privilegiado a menudo se denomina modo usuario, porque los programas de usuario típicamente se ejecutan en este modo. El modo más privilegiado se denomina modo sistema, modo control o modo núcleo.
El motivo por el cual se usan los otros modos es claro. Se necesita proteger al sistema operativo y a las tablas clave del sistema, por ejemplo los bloques de control de proceso, de la interferencia con programas de usuario. 

En modo núcleo, el software tiene control completo del procesador y de sus instrucciones, registros, y memoria. Este nivel de control no es necesario y por seguridad no es recomendable para los programas de usuario.  —

Estructuras de control del S.O

Las tablas de memoria se usan para mantener un registro tanto de la memoria principal (real) como de la secundaria (virtual). Parte de la memoria principal está reservada para el uso del sistema operativo; el resto está disponible para el uso de los procesos. Los procesos se mantienen en memoria secundaria utilizando algún tipo de memoria virtual o técnicas de swapping.  Las tablas de memoria deben incluir la siguiente información: –Las reservas de memoria principal por parte de los procesos. 

Las reservas de memoria secundaria por parte de los procesos. –Todos los atributos de protección que restringe el uso de la memoria principal y virtual, de forma que los procesos puedan acceder a ciertas áreas de memoria compartida. La información necesaria para manejar la memoria virtual. El sistema operativo debe utilizar las tablas de E/S para gestionar los dispositivos de E/S y los canales del computador. Pero, en un instante determinado, un dispositivo E/S puede estar disponible o asignado a un proceso en particular. Si la operación de E/S se está realizando, el sistema operativo necesita conocer el estado de la operación y la dirección de memoria principal del área usada como fuente o destino de la transferencia de E/S.  El sistema operativo también puede mantener las tablas de ficheros o tabla de archivos.
Estas tablas proporcionan información sobre la existencia de ficheros, su posición en almacenamiento secundario, su estado actual, y otros atributos. La mayoría de, o prácticamente toda, esta información se puede gestionar por el sistema de ficheros, en cuyo caso el sistema operativo tiene poco o ningún conocimiento sobre los ficheros. En otros sistemas operativos, la gran mayoría del detalle de la gestión de ficheros sí que gestiona en el propio sistema operativo. En último lugar, el sistema operativo debe mantener tablas de procesos para gestionar los procesos. Estas tablas están conformadas por todos los PCB. —

Planificación de procesos

La planificación de procesos se refiere a cómo determina el sistema operativo al orden en que irá cediendo el uso del procesador a los procesos que lo vayan solicitando, y a las políticas que empleará para que el uso que den a dicho tiempo no sea excesivo respecto al uso esperado del sistema. El objetivo de la planificación de procesos es asignar procesos a ser ejecutados por el procesador o procesadores a lo largo del tiempo, de forma que se cumplan los objetivos del sistema tales como el tiempo de respuesta, el rendimiento y la eficiencia del procesador. 

Objetivos de la planificación de procesos: –

Ser justo:

Debe tratarse de igual manera a todos los procesos que compartan las mismas carácterísticas, y nunca postergar indefinidamente a uno de ellos. –

Maximizar el rendimiento:

Dar servicio a la mayor parte de procesos por unidad de tiempo. –

Ser predecible:

Un mismo trabajo debe tomar aproximadamente la misma cantidad de tiempo en completarse independientemente de la carga del sistema. –

Minimizar la sobrecarga:

El tiempo que el algoritmo pierda en burocracia debe mantenerse al mínimo, dado que éste es tiempo de procesamiento útil perdido. –

Equilibrar el uso de recursos:

Favorecer a los procesos que empleen recursos subutilizados, penalizar a los que peleen por un recurso sobreutilizado causando contención en el sistema. –

Evitar la postergación indefinida:

Aumentar la prioridad de los procesos más viejos, para favorecer que alcancen a obtener algún recurso por el cual estén esperando. –

Favorecer el uso esperado del sistema:

En un sistema con usuarios interactivos, maximizar la prioridad de los procesos que sirvan a solicitudes iniciadas por éste (aún a cambio de penalizar a los procesos /de sistema). –

Dar preferencia a los procesos que podrían causar bloqueo:

Si un proceso de baja prioridad está empleando un recurso del sistema por el cual más procesos están esperando, favorecer que éste termine de emplearlo más rápido. –

Favorecer a los procesos con un comportamiento deseable:

Si un proceso causa muchas demoras (por ejemplo, atraviesa una ráfaga de entrada/salida que le requiere hacer muchas llamadas a sistema o interrupciones), se le puede penalizar porque degrada el rendimiento global del sistema. –

Degradarse suavemente:

Si bien el nivel ideal de utilización del procesador es al 100%, es imposible mantenerse siempre a este nivel. Un algoritmo puede buscar responder con la menor penalización a los procesos preexistentes al momento de exceder este umbral. –

Tipos de planificación

Existen tres tipos principales de planificación: -El planificador a largo plazo determina qué programas se admiten en el sistema para su procesamiento. De esta forma, se controla el grado de multiprogramación. Una vez admitido, un trabajo o programa de usuario se convierte en un proceso y se añade a la cola del planificador a corto plazo. En algunos sistemas, un proceso de reciente creación comienza en la zona de intercambio, en cuyo caso se añaden a la cola del planificador a medio plazo. En un sistema por lotes, o en la parte de lotes de un sistema operativo de propósito general, los nuevos trabajos enviados se mandan al disco y se mantienen en una cola de lotes. El planificador a largo plazo creará procesos desde la cola siempre que pueda. En este caso hay que tomar dos decisiones. La primera, el planificador debe decidir cuándo el sistema operativo puede coger uno o más procesos adicionales. La segunda, el planificador debe decidir qué trabajo o trabajos se aceptan y son convertidos en procesos. -El planificador a mediano plazo decide cuáles procesos es conveniente bloquear en determinado momento, sea por escasez/saturación de algún recurso (como la memoria primaria) o porque están realizando alguna solicitud que no puede satisfacerse momentáneamente; se encarga de tomar decisiones respecto a los procesos conforme entran y salen del estado de bloqueado (esto es, típicamente, están a la espera de algún evento externo o de la finalización de transferencia de datos con algún dispositivo).Al planificador a mediano plazo se le llama scheduler. -El planificar a corto plazo decide cómo compartir momento a momento al equipo entre todos los procesos que requieren de sus recursos, especialmente el procesador. La planificación a corto plazo se lleva a cabo decenas de veces por segundo (razón por la cual debe ser código muy simple, eficiente y rápido); es el encargado de planificar los procesos que están listos para ejecución. El planificador a corto plazo es también frecuentemente denominado dispatcher. 

Anidamiento de las funciones de planificación en el diagrama de transición de estados

Relacionando con los estados de un proceso, podrían ubicarse a estos tres planificadores en las siguientes transiciones entre estados: 1. El planificador a largo plazo se encarga de admitir un nuevo proceso: La transición de Nuevo a Listo. 2. El planificador a mediano plazo maneja la activación y bloqueo de un proceso relacionado con eventos — Esto es, las transiciones entre En  ejecución y Bloqueado, y entre Bloqueado y Listo. 3. El planificador a corto plazo decide entre los procesos que están listos para ejecutarse y determina a cuál de ellos activar, y detiene a aquellos que exceden su tiempo de procesador— Implementa las transiciones entre los estados Listo y En ejecución.

–Funciones del planificador

El Scheduleres el programa dentro del sistema operativo que administra de manera eficiente el procesador, es parte del núcleo del sistema operativo. Funciones principales: a. Dar de alta el PCB. B.Hacer actualizaciones al PCB. C.Dar de baja el PCB. D. Asigna tiempos de ejecución a cada proceso e.Organiza la fila de listos y bloqueados. El Planificador de trabajos o Scheduler se encarga de elegir la tarea siguiente que hay que admitir en el sistema y el proceso siguiente que hay que ejecutar. Su finalidad es asignar procesos para que sean ejecutados por el procesador o procesadores con el fin de obtener mejores tiempos de respuesta, mayor productividad o rendimiento y eficiencia del procesador. 

El planificador a corto plazo o dispatcher (despachador)es un pequeño programa que tiene la misión de asignar la CPU a uno de los procesos ejecutables del sistema, para ello sigue un determinado algoritmo. Los acontecimientos que pueden provocar la llamada al dispatcher dependen del sistema (son un subconjunto de las interrupciones), pero son alguno de estos: El proceso en ejecución acaba su ejecución o no puede seguir ejecutándose (por una E/S, operación WAIT, etc.). Un elemento del sistema operativo ordena el bloqueo del proceso en ejecución. El proceso en ejecución agota su quantum de estancia en la CPU. Un proceso pasa a estado listo.

Estado de un proceso

Un proceso, a lo largo de su vida, alterna entre diferentes estados de ejecución. Básicamente el estado indicará si un proceso está haciendo algo o no. Si no está ejecutando, además especificará por qué. 

Diagrama de 7 estados de procesos Estados:   –

Ejecutando:

El proceso está actualmente en ejecución. Para este capítulo asumimos que el computador tiene un único procesador, de forma que sólo un proceso puede estar en este estado en un instante determinado. –

Listo:

Un proceso que se prepara para ejecutar cuando tenga oportunidad. –

Bloqueado:

Un proceso que no puede ejecutar hasta que se cumpla un evento determinado o se complete una operación E/S. –

Nuevo:

Un proceso que se acaba de crear y que aún no ha sido admitido en el grupo de procesos ejecutables por el sistema operativo. Típicamente, se trata de un nuevo proceso que no ha sido cargado en memoria principal, aunque su bloque de control de proceso (BCP) si ha sido creado. –

Saliente:

Un proceso que ha sido liberado del grupo de procesos ejecutables por el sistema operativo, debido a que ha sido detenido o que ha sido abortado por alguna razón.

Bloqueado/Suspendido:

El proceso está en almacenamiento secundario y esperando un evento.

Listo/Suspendido:

El proceso está en almacenamiento secundario pero está disponible para su ejecución tan pronto como sea cargado en memoria principal. 

Transiciones:

Null ®  Nuevo
. Se crea un nuevo proceso para ejecutar un programa.
Nuevo ® Listo.
El sistema operativo mueve a un proceso del estado nuevo al estado listo cuando éste se encuentre preparado para ejecutar un nuevo proceso. La mayoría de sistemas fijan un límite basado en el número de procesos existentes o la cantidad de memoria virtual que se podrá utilizar por parte de los procesos existentes. Este límite asegura que no haya demasiados procesos activos y que se degrade el rendimiento sistema. –
Listo ® Ejecutando.
Cuando llega el momento de seleccionar un nuevo proceso para ejecutar, el sistema operativo selecciona uno los procesos que se encuentre en el estado Listo. Esta es una tarea la lleva acabo el dispatcher. –
Ejecutando ® Saliente.
el proceso actual en ejecución se finaliza por parte del sistema operativo tanto si el proceso indica que ha completado su ejecución como si éste se aborta. –
Ejecutando ® Listo.
La razón más habitual para esta transición es que el proceso en ejecución haya alcanzado el máximo tiempo posible de ejecución de forma ininterrumpida; prácticamente todos los sistemas operativos multiprogramados imponen este tipo de restricción de tiempo. –
Ejecutando ® Bloqueado.
Un proceso se pone en el estado Bloqueado si solicita algo por lo cual debe esperar. Una solicitud al sistema operativo se realiza habitualmente por medio de una llamada al sistema; esto es, una llamada del proceso en ejecución a un procedimiento que es parte del código del sistema operativo. –
Bloqueado ® Listo.
Un proceso en estado Bloqueado se mueve al estado Listo cuando sucede el evento por el cual estaba esperando. –
Listo ® Saliente.
Por claridad, esta transición no se muestra en el diagrama de estados. En algunos sistemas, un padre puede terminar la ejecución de un proceso hijo en cualquier momento. También, si el padre termina, todos los procesos hijos asociados con dicho padre pueden finalizarse. –
Bloqueado ® Saliente.
Se aplican los comentarios indicados en el caso anterior. –Bloqueado ® Bloqueado/Suspendido.
Si no hay procesos listos, entonces al menos uno de los procesos bloqueados se transfiere al disco para hacer espacio para otro proceso que no se encuentra bloqueado. Esta transición puede realizarse incluso si hay procesos listos disponibles, si el sistema operativo determina que el proceso actualmente en ejecución o los procesos listos que desea ejecutar requieren más memoria principal para mantener un rendimiento adecuado. –
Bloqueado/Suspendido ® Listo/Suspendido.
Un proceso en el estado Bloqueado/Suspendido se mueve al estado Listo/Suspendido cuando sucede un evento al que estaba esperando. Nótese que esto requiere que la información de estado concerniente a un proceso suspendido sea accesible para el sistema operativo. –
Listo/Suspendido ® Listo.
Cuando no hay más procesos listos en memoria principal, el sistema operativo necesitará traer uno para continuar la ejecución. Adicionalmente, puede darse el caso de que un proceso en estado Listo/Suspendido tenga mayor prioridad que cualquiera de los procesos en estado Listo. En este caso, el sistema operativo puede haberse diseñado para determinar que es más importante traer un proceso de mayor prioridad que para minimizar el efecto del swapping. –Listo ® Listo/Suspendido.
Normalmente, el sistema operativo preferirá suspender procesos bloqueados que un proceso Listo, porque un proceso Listo se puede ejecutar en ese momento, mientras que un proceso Bloqueado ocupa espacio de memoria y no se puede ejecutar. Sin embargo, puede ser necesario suspender un proceso Listo si con ello se consigue liberar un bloque suficientemente grande de memoria. También el sistema operativo puede decidir suspender un proceso Listo de baja prioridad antes que un proceso Bloqueado de alta prioridad, si se cree que el proceso Bloqueado estará pronto listo. –
Nuevo ®  Listo/Suspendido y Nuevo a Listo
. Cuando se crea un proceso nuevo, puede añadirse a la cola de Listos o a la cola de Listos/Suspendidos. En cualquier caso, el sistema operativo puede crear un bloque de control de proceso (BCP) y reservar el espacio de direcciones del proceso. –
Bloqueado/Suspendido ® Bloqueado.
considéresé el siguiente escenario: un proceso termina, liberando alguna memoria principal. Hay un proceso en la cola de Bloqueados/Suspendidos con mayor prioridad que todos los procesos en la cola de Listos/Suspendidos y el sistema operativo tiene motivos para creer que el evento que lo bloquea va a ocurrir en breve. Bajo estas circunstancias, sería razonable traer el proceso Bloqueado a memoria por delante de los procesos Listos. –
Ejecutando ® Listo/Suspendido.
Normalmente, un proceso en ejecución se mueve a la cola de Listos cuando su tiempo de uso del procesador finaliza. Sin embargo, si el sistema operativo expulsa al proceso en ejecución porque un proceso de mayor prioridad en la cola de Bloqueado/Suspendido acaba de desbloquearse, el sistema operativo puede mover al proceso en ejecución

directamente a la cola de Listos/Suspendidos y liberar parte de la memoria principal.
De cualquier estado ® Saliente.
Habitualmente, un proceso termina cuando está ejecutando, bien porque ha completado su ejecución o debido a una condición de fallo. Sin embargo, en algunos sistemas operativos un proceso puede terminarse por el proceso que lo creó o cuando el proceso padre a su vez ha terminado. Si se permite esto, un proceso en cualquier estado puede moverse al estado Saliente.

Creación de procesos: 1

Asignar un identificador de proceso único al proceso

En este instante, se añade una nueva entrada a la tabla primaria de procesos, que contiene una entrada por proceso.

2

Reservar espacio para proceso

Esto incluye todos los elementos de la imagen del proceso. Para ello, el sistema operativo debe conocer cuánta memoria se requiere para el espacio de direcciones privado (programas y datos) y para la pila de usuario. Estos valores se pueden asignar por defecto basándonos en el tipo de proceso, o pueden fijarse en base a la solicitud de creación del trabajo remitido por el usuario. Si un proceso es creado por otro proceso, el proceso padre puede pasar los parámetros requeridos por el sistema operativo como parte de la solicitud de la creación de proceso. Si existe una parte del espacio direcciones compartido por este nuevo proceso, se fijan los enlaces apropiados. Por último, se debe reservar el espacio para el bloque de control de proceso (BCP). 

2

Inicialización del bloque de control de proceso

La parte de identificación de proceso del BCP contiene el identificador del proceso así como otros posibles identificadores, tal como el indicador del proceso padre. En la información de estado de proceso del BCP, habitualmente se inicializa con la mayoría de entradas a 0, excepto el contador de programa (fijado en el punto entrada del programa) y los punteros de pila de sistema (fijados para definir los límites de la pila del proceso). La parte de información de control de procesos se inicializa en base a los valores por omisión, considerando también los atributos que han sido solicitados para este proceso. Por ejemplo, el estado del proceso se puede inicializar normalmente a Listo o Listo/Suspendido. La prioridad se puede fijar, por defecto, a la prioridad más baja, a menos que una solicitud explicita la eleve a una prioridad mayor. Inicialmente, el proceso no debe poseer ningún recurso (dispositivos de E/S, ficheros) a menos que exista una indicación explícita de ello o que haya sido heredados del padre. 

3

Establecer los enlaces apropiados

Por ejemplo, si el sistema operativo mantiene cada cola del planificador como una lista enlazada, el nuevo proceso debe situarse en la cola de Listos o en la cola de Listos/Suspendidos. 

4

Creación o expansión de otras estructuras de datos

Por ejemplo, el sistema operativo puede mantener un registro de auditoría por cada proceso que se puede utilizar posteriormente a efectos de facturación y/o de análisis de rendimiento del sistema. 

Cambio de procesos

Para llevar a cambio un proceso el SO deberá –

¿Qué sucesos provocan un cambio de proceso?

Un cambio de proceso puede suceder en cualquier instante en el que el sistema operativo gana el control de la CPU. En primer lugar, se van a tener en cuenta las interrupciones del sistema. Se pueden distinguir dos clases de interrupciones del sistema. –La primera es originada por algún tipo de suceso que es externo e independiente del proceso que se está ejecutando, como la culminación de una E/S. –La segunda tiene que ver con una condición de error o excepción generada dentro del proceso que se está ejecutando, como un intento ilegal de acceso a un fichero, una división entre cero, una instrucción máquina con código de operación no contemplado. –En una interrupción ordinaria, el control se transfiere primero al gestor de interrupciones, quien lleva a cabo algunas tareas básicas y, después, se salta a la rutina del sistema operativo que se ocupa del tipo de interrupción que se ha producido. Algunos ejemplos de estas interrupciones son: –Interrupción de reloj: Un reloj es un dispositivo que genera interrupciones periódicamente. Ante una interrupción de este tipo, un sistema operativo de tiempo compartido, entre otras cosas, determina si el proceso en ejecución ha alcanzado el máximo tiempo de ejecución que se le concedíó. Si es así, el proceso pasará a estado listo, y se asignará la CPU a otro proceso. –Interrupción de E/S: El sistema operativo determina exactamente qué acción de E/S ha ocurrido. Si se trata de un evento o suceso por el que esperaban uno o más procesos, entonces el sistema operativo traslada todos los procesos bloqueados en dicho evento al estado listo, y determina (dependiendo de la política de planificación, que se verá en el próximo tema) si reanuda la ejecución del proceso interrumpido o pasa a otro de mayor prioridad. –Falta de memoria: Un proceso hace una referencia a una dirección que no se encuentra en memoria y que debe traerse de memoria secundaria (esta posibilidad se estudiará en el módulo de gestión de la memoria). Después de hacer la solicitud de E/S para traer esa o esas direcciones de memoria, el sistema operativo lleva a cabo un cambio de contexto (próximo apartado) para reanudar la ejecución de otro proceso; el proceso que cometíó la falta de memoria se pasa al estado bloqueado. Después de que las direcciones aludidas se carguen en memoria, dicho proceso se pondrá en estado listo. En una interrupción del segundo tipo, el sistema operativo determina si el error es fatal. Si lo es, el proceso que se estaba ejecutando es eliminado, y se produce un cambio de proceso. Si no es fatal, la acción del sistema operativo dependerá de la naturaleza del error y del diseño del sistema operativo. Se puede hacer un cambio de proceso o, simplemente, reanudar el mismo proceso que se estaba ejecutando. Finalmente, el sistema operativo puede activarse mediante una llamada al sistema desde el programa que se está ejecutando. Por ejemplo, está ejecutándose un proceso de usuario y se llega a una instrucción que solicita una operación de E/S, tal como abrir un fichero. Esta llamada provoca la transferencia a una rutina que forma parte del código del sistema operativo. Por lo general (aunque no siempre) el uso de una llamada al sistema hace que el proceso de usuario pase al estado bloqueado. 

¿Hay necesidad de cambio de contexto?

Si existe una interrupción pendiente es necesario: – Salvar el contexto (PC, registros del procesador, información de la pila) del programa en ejecución. –Poner en el PC la dirección del programa de tratamiento de la interrupción, que suele constar de unas pocas tareas básicas. Una pregunta que puede plantearse es: –

¿qué es lo que constituye el contexto que se debe salvar?

La respuesta es que se debe incluir información que pueda ser necesaria para reanudar el programa interrumpido. Así pues, debe guardarse la parte del bloque de control del proceso denominada información de estado del procesador. Esto incluye al contador de programa, otros registros del procesador y la información de la pila. –

¿Se tiene que hacer algo más?

Ello dependerá de lo que ocurra a continuación. La rutina de tratamiento de la interrupción es normalmente un programa corto que lleva a cabo unas pocas tareas básicas relacionadas con una interrupción. Por ejemplo, se marca el indicador que señala la presencia de una interrupción, puede enviar un acuse de recibo a la entidad que produjo la interrupción (como un módulo de E/S)

y puede hacer algunas tareas básicas relacionadas con los efectos del suceso que causó la interrupción. Por ejemplo, si la interrupción está relacionada con un suceso de E/S, el gestor de interrupciones comprobará condiciones de error. Si se ha producido un error, la rutina de tratamiento puede enviar una señal al proceso que solicitó originalmente la operación de E/S.

¿Hay que hacer algo más?

Pues depende de si la interrupción va a venir seguida de un cambio de proceso o no. La ocurrencia de una interrupción no siempre causa el cambio de proceso. Es posible que después de que el gestor de interrupciones se haya ejecutado, el proceso que estaba ejecutándose reanude su ejecución. En tal caso, tan sólo hay que guardar la información de estado del procesador y restaurarla para que pueda reanudarse correctamente el proceso interrumpido (estas funciones son realizadas en hardware).

Establecer los pasos a seguir dadas las diferentes alternativas

Los pasos involucrados en un cambio completo de proceso son los siguientes: 1. Salvar el contexto del procesador, incluyendo el contador de programa y otros registros. 2. Actualizar el PCB que estaba en estado de ejecución. Esto implica cambiar el estado del proceso a alguno de los otros estados (listo, bloqueado, suspendido_listo). También se tienen que actualizar otros campos, como uno en el que se guarde la razón por la que se abandona el estado de ejecución y otros con información de contabilidad. 3. Mover el PCB a la cola apropiada (listos, bloqueados por el suceso i, suspendido_listo). 4. Seleccionar otro proceso para ejecución (como veremos en el tema de Planificación de Procesos). 5. Actualizar el PCB seleccionado. Cambiar, por ejemplo, su estado a ‘en ejecución’. 6. Actualizar las estructuras de datos de gestión de la memoria. Esto puede hacer falta dependiendo de cómo se gestione la traducción de direcciones (lo dejaremos para los temas sobre memoria). Restaurar el contexto del procesador a aquél que existía en el momento en el que el proceso seleccionado dejó por última vez el estado de en ejecución, cargando los valores previos del contador de programa y de otros registros. Así pues, el cambio de proceso, que implica un cambio de contexto, requiere un esfuerzo considerablemente superior al de un cambio de contexto. 

Diferencias entre cambio de proceso y cambio de contexto

El cambio de contexto es un concepto distinto al cambio de un proceso. Puede ocurrir un cambio de contexto sin cambiar el estado del proceso que está actualmente en estado de ejecución. En tal caso, salvar el contexto y restaurarlo posteriormente involucra un pequeño coste extra. Sin embargo, si el proceso que estaba ejecutándose tiene que pasar a otro estado (listo o bloqueado), el sistema operativo tiene que llevar a cabo cambios substanciales en su entorno (contexto).  

Criterio de planificación a corto plazo. Orientados al usuario, relacionados con las prestaciones. –

Tiempo de estancia (turnaround time):

Tiempo transcurrido desde que se lanza un proceso hasta que finaliza. Incluye el tiempo de ejecución sumado con el tiempo de espera por los recursos, incluyendo el procesador. Es una medida apropiada para trabajos por lotes. –

Tiempo de respuesta (response time):

Para un proceso interactivo, es el tiempo que trascurre desde que se lanza una petición hasta que se comienza a recibir la respuesta. A menudo un proceso puede producir alguna salida al usuario mientras continúa el proceso de la petición. De esta forma, desde el punto de vista del usuario, es una medida mejor que el tiempo de estancia. La planificación debe intentar lograr bajos tiempos de respuesta y maximizar el número de usuarios interactivos con tiempos de respuesta aceptables. –

Fecha tope (deadlines):

Cuando se puede especificar la fecha tope de un proceso, el planificador debe subordinar otros objetivos al de maximizar el porcentaje de fechas tope conseguidas.

Previsibilidad

: Un trabajo dado debería ejecutarse aproximadamente en el mismo tiempo y con el mismo coste a pesar de la carga del sistema. Una gran variación en el tiempo de respuesta o en el tiempo de estancia es malo desde el punto de vista de los usuarios. Puede significar una gran oscilación en la sobrecarga del sistema o la necesidad de poner a punto el sistema para eliminar las inestabilidades. 

Orientados al sistema, relacionados con las prestaciones: –

Rendimiento

: La política de planificación debería intentar maximizar el número de procesos completados por unidad de tiempo. Es una medida de cuánto trabajo está siendo realizado. Esta medida depende claramente de la longitud media de los procesos, pero está influenciada por la política de planificación, que puede afectar a la utilización.

Utilización del procesador:

Es el porcentaje de tiempo que el procesador está ocupado. Para un sistema compartido costoso, es un criterio significativo. En un sistema de un solo usuario y en otros sistemas, tales como los sistemas de tiempo real, este criterio es menos importante que algunos otros. –

Equidad:

En ausencia de orientación de los usuarios o de orientación proporcionada por otro sistema, los procesos deben ser tratados de la misma manera, y ningún proceso debe sufrir inanición. –

Imposición de prioridades:

Cuando se asignan prioridades a los procesos, la política del planificador debería favorecer a los procesos con prioridades más altas. –

Equilibrado de recursos:

La política del planificador debería mantener ocupados los recursos del sistema. Los procesos que utilicen poco los recursos que en un determinado momento están sobreutilizados, deberían ser favorecidos. Este criterio también implica planificación a medio plazo y a largo plazo. 

Política de uso de CPU implementados en los algoritmos –

Sin expulsión (nonpreemptive)

En este caso, una vez que el proceso está en el estado Ejecutando, continúa ejecutando hasta que termina o se bloquea para esperar E/S o para solicitar algún servicio al sistema operativo. –

Con expulsión (preemptive)

Un proceso ejecutando en un determinado momento puede ser interrumpido y pasado al estado de listo por el sistema operativo. La decisión de expulsar puede ser tomada cuando llega un nuevo proceso, cuando llega una interrupción que pasa un proceso de bloqueado a estado de listo, o periódicamente, basándose en las interrupciones del reloj. 

Algoritmos de planificación: –

FCFS: First Come First Served – Atención por orden de llegada (FIFO) –

Política sin desalojo. – Todos los procesos entran a la cola de listos. –Cuando el proceso actual deja de correr, el siguiente proceso en la cola de listos es seleccionado. –Un pequeño grupo de procesos puede esperar largos periodos de tiempo antes de ser ejecutados. –Favorece los procesos con carga del procesador en lugar de los que tienen carga de E/S. –

RR: Round Robín o Turno Rotatorio –

Política con desalojo. –Prevención del uso basada en un reloj. –Cada quantum de tiempo un proceso usa la CPU. –Las interrupciones de reloj se generan en intervalos fijos. – Cuando ocurre una interrupción, el proceso en ejecución es colocado en la cola de listos y el siguiente proceso es seleccionado. –

VRR: Virtual Round Robín o Turno Rotatorio Virtual: –

Política con desalojo. Planifica similar a Round Robín, pero la cola de bloqueados tiene prioridad sobre la cola de listos. – Se implementa a través de una cola auxiliar. –Si hay procesos en la Cola Auxiliar, se ejecutarán antes de volver a tomar procesos de la Cola de Listos.

SPN: Shotest Process Next (Equivale a SJF Sin desalojo): –

Política sin desalojo. –Proceso con tiempo esperado más corto es seleccionado. –Los procesos pequeños saltan delante de los grandes. –La predictibilidad de los procesos grandes es reducida (Predictability). –Si el tiempo estimado es incorrecto, el SO puede abortarlo. –Posibilidad de inanición de los procesos grandes. –

SRT: Shortest Remaining Time (Equivale a SJF Con desalojo): –

Política con desalojo. –Versión preventiva de la política el siguiente proceso más corto. – Elige proceso que le queda menos tiempo esperado de ejecución. – Existe riesgo de inanición para procesos largos. –

HRRN: Highest Ratio Response Next (Mayor tasa de respuesta): –

Es una adaptación del SJF que permite romper la inanición. –Se prioriza a los procesos con mayor tasa de respuesta (Response Ratio):  R.R. = (S + W) / S. –S = Tiempo de servicio (próxima ráfaga). -W = Espera. –Cuanto mayor sea la espera, respecto al tamaño de su ráfaga, mayor será su prioridad para ejecutar. –

Feedback: Retroalimentación de nivel múltiple: –

Penaliza los trabajos que han corrido más tiempo (Q). – Si no se conoce el tiempo de ejecución restante, entonces es mejor utilizar el tiempo de ejecución consumido hasta el momento. –Mecanismo dinámico de prioridades: varias colas de listos de acuerdo a prioridad. –Entra 1ra vez cola RQ0. – Luego de la ejecución i a cola prioridad i –1. – Favorece procesos cortos y nuevos frente a los mas viejos y largos. –

Política por Prioridades: –

Se asocia con cada proceso una prioridad (número entero). – La CPU se asigna al proceso con la prioridad más alta (consideramos número pequeño ≡ prioridad alta). – Tenemos dos posibilidades: –Expropiativo. –No expropiativo. – SJF se puede ver como un algoritmo de planificación por prioridad en el que la prioridad es la duración predicha para la siguiente ráfaga de CPU. –Problema: Inanición (starvation) –los procesos de más baja prioridad podrían no ejecutarse nunca. –Solución: Envejecimiento (aging) –conforme el tiempo pasa aumentar la prioridad de los procesos que esperan mucho en el sistema. 

Concepto de hilo:

Un hilo o proceso ligero es una unidad básica de ejecución, con su propio: contador de programa registros de CPU pila (stack). Definimos como Hilo, a la traza o ejecución de acciones esperadas de un proceso, basadas en la programación del mismo, a su vez es una unidad de Planificación que utiliza el CPU y que comprende: Un ID de hilo, un set de registros (Como un PC, SP, IP, etc.) y una pila propios. 

Proceso Multihilos

Multihilo se refiere a la capacidad de un sistema operativo de dar soporte a múltiples hilos de ejecución en un solo proceso.   En un entorno multihilo, un proceso se define como la unidad de asignación de recursos y una unidad de protección. Se asocian con procesos los siguientes: – Un espacio de direcciones virtuales que soporta la imagen del proceso. –Acceso protegido a procesadores, otros procesos (para comunicación entre procesos), archivos y recursos de E/S (dispositivos y canales). –Dentro de un proceso puede haber uno o más hilos, cada uno con: – Un estado de ejecución por hilo (Ejecutando, Listo, etc.). – Un contexto de hilo que se almacena cuando no está en ejecución; una forma de ver a un hilo es como un contador de programa independiente dentro de un proceso. –Una pila de ejecución. –Por cada hilo, espacio de almacenamiento para variables locales. –Acceso a la memoria y recursos de su proceso, compartido con todos los hilos de su mismo proceso.

Ventajas de la implementación de hilos. –

Velocidad de respuesta (Responsiveness): Hacer una aplicación “multihilos” puede permitir al programa continuar ejecutando cuando alguno de sus hilos se bloquea (aunque no siempre!), cuando hace alguna operación que toma mucho tiempo. – Compartición de Recursos: Los hilos comparten la memoria y los recursos de los procesos a los que pertenecen. -Economía: – Dado que los hilos en un proceso comparten los recursos, es más económico crear y cambiar contextos de hilos. – La creación de un proceso (por ejemplo la JVM en Windows) es alrededor de 30 veces más lenta que la creación de un hilo. –Utilización de Multiprocesamiento y Arquitecturas Multi-Procesador: Determinado tipo de hilos pueden ejecutarse en diferentes procesadores paralelamente. 

Tipos de implementación de hilos: –

Hilos de Usuario (User Level Threads) o ULTs

. Son visibles para el programador pero no para el SO. En un entorno ULT puro, la aplicación gestiona todo el trabajo de los hilos y el núcleo no es consciente de la existencia de los mismos. Cualquier aplicación puede programarse para ser multihilo a través del uso de una biblioteca de hilos, que es un paquete de rutinas para la gestión de ULT. La biblioteca de hilos contiene código para la creación y destrucción de hilos, para paso de mensajes y datos entre los hilos, para planificar la ejecución de los hilos, y para guardar y restaurar el contexto de los hilos. –

Hilos de Núcleo (Kernel Level Threads) o KLTs

Son visibles para el SO. En un entorno KLT puro, el núcleo gestiona todo el trabajo de gestión de hilos. No hay código de gestión de hilos en la aplicación, solamente una interfaz de programación de aplicación para acceder a las utilidades de hilos del núcleo. –

Enfoques combinados

Algunos sistemas operativos proporcionan utilidades combinadas ULT/KLT. En un sistema combinado, la creación de hilos se realiza por completo en el espacio de usuario, como la mayor parte de la planificación y sincronización de hilos dentro de una aplicación. Los múltiples ULT de una aplicación se asocian en un número (menor o igual) de KLT. El programador debe ajustar el número de KLT para una máquina y aplicación en particular para lograr los mejores resultados posibles. En los enfoques combinados, múltiples hilos de la misma aplicación pueden ejecutar en paralelo en múltiples procesadores, y una llamada al sistema bloqueante no necesita bloquear el proceso completo. Si el sistema está bien diseñado, este enfoque debería combinar las ventajas de los enfoques puros ULT y KLT, minimizando las desventajas. 

Ventajas y desventajas de los ULTs y KLTs. Ventajas de los ULTs: –

Pueden implementarse en las aplicaciones que se ejecutaban en sistemas operativos que no son capaces de planificar hilos. –No generan Overhead al SO. –No hay límite en la cantidad de ULTs que pueden crearse asociados al mismo LWP y su correspondiente KLT. 

Desventajas de los ULTs:

No son vistos por el SO por lo que su planificación queda atada a la experiencia del programador. –Utilizan un único procesador en ambientes multiprocesador. –Una Llamada al sistema bloqueante bloquea el LWP y su KLT asociado, por lo que ningún otro hilo dependiente de este KLT podrá ejecutar. 

Ventajas de los KLTs: –

El proceso de usuario no se tiene que encargar de la planificación de los hilos. – Si tenemos un procesador con más de un núcleo, el Sistema operativo puede planificar los hilos en diferentes núcleos. –El bloqueo de un hilo no bloquea la ejecución del resto (ya que los ve el SO como procesos ligeros separados). –

Desventajas de los KLTs: –

Causan mayor Overhead en determinados modelos (Ej. Uno-a-Uno). –Limitados por la disponibilidad del manejo de hilos del SO. Muchos KLTs pueden causar excesiva “sobrecarga” (Overhead). –Limitados a la aplicación o máquina utilizadas. –Mayor costo de creación y administración que los ULTs.

Relacionan de los hilos ULTs y KLTs. Modelo 1×1 (one to one) –

Cada Hilo de usuario se mapea con un hilo de Kernel. Hay mayor nivel de competitividad por recursos que en el modelo Muchos a Uno. Permite ejecutar otros hilos de Kernel cuando alguno de ellos está bloqueado.

Modelo Mx1 (Many to one). –

Muchos hilos de Usuario mapeados a un único hilo de Kernel. La administración de los hilos es realizada por la Biblioteca de Hilos. –Es eficiente. Se pueden crear tantos hilos como se desee. –Todo el Proceso/KLT se va a bloquear si se hace una Llamada al Sistema bloqueante. –Aunque se tengan múltiples procesadores, los hilos de estas combinaciones sólo utilizarán uno.

Modelo MxN (many to many) –

El modelo multiplexa muchos hilos de usuario sobre un número menor o igual de hilos del kernel. –Cada proceso tiene asignado un conjunto de hilos de kernel, independientemente de la cantidad de hilos de usuario que haya creado. –No posee ninguno de los inconvenientes de los dos modelos anteriores, ya que saca lo mejor de cada uno. –El usuario puede crear tantos hilos como necesite y los hilos de kernel pueden ejecutar en paralelo. –Asimismo, cuando un hilo se bloquea, el kernel puede planificar otro hilo para su ejecución. –Entonces, el planificador a nivel de usuario asigna los hilos de usuario a los hilos de kernel, y el planificador a nivel de kernel asigna los hilos de kernel a los procesadores. 

Biblioteca de hilos:

Una Biblioteca de Hilos provee al programador una API* para crear y manejar los hilos. Dos formas de implementación. Biblioteca entera en el espacio de Usuario sin soporte para Kernel. Todos los datos y estructuras de la librería existen en el espacio de Usuario. –Todas las funciones y llamadas se realizan en el espacio de Usuario. –Funciones a nivel de kernel soportadas por el SO. Todos los datos y estructuras existen en el espacio de Kernel o Núcleo. –El invocado de funciones puede resultar en System Calls al Kernel.   . Una API (Application Programming Interface) es un conjunto de funciones que sirven al programador para comunicar diferentes sistemas, o manejar funcionalidades específicas en la programación de alguno de ellos. Por ejemplo, la Biblioteca de hilos provee funciones para comunicarse con el Kernel. 

Planificación de hilos

En un sistema operativo que soporte hilos, la planificación y la activación se realizan a nivel de hilo; de aquí que la mayor parte de la información de estado relativa a la ejecución se mantenga en estructuras de datos a nivel de hilo. Existen, sin embargo, diversas acciones que afectan a todos los hilos de un proceso y que el sistema operativo debe gestionar a nivel de proceso. Suspender un proceso implica expulsar el espacio de direcciones de un proceso de memoria principal para dejar hueco a otro espacio de direcciones de otro proceso. Ya que todos los hilos de un proceso comparten el mismo espacio de direcciones, todos los hilos se suspenden al mismo tiempo. De forma similar, la finalización de un proceso finaliza todos los hilos de ese proceso.

Estados de los hilos

Igual que con los procesos, los principales estados de los hilos son: Ejecutando, Listo y Bloqueado. Generalmente, no tiene sentido aplicar estados de suspensión a un hilo, ya que dichos estados son conceptos de nivel de proceso. En particular, si se expulsa un proceso, todos sus hilos se deben expulsar porque comparten el espacio de direcciones del proceso. Hay cuatro operaciones básicas relacionadas con los hilos que están asociadas con un cambio de estado del hilo: –

Creación

Cuando se crea un nuevo proceso, también se crea un hilo de dicho proceso. Posteriormente, un hilo del proceso puede crear otro hilo dentro del mismo proceso, proporcionando un puntero a las instrucciones y los argumentos para el nuevo hilo. Al nuevo hilo se le proporciona su propio registro de contexto y espacio de pila y se coloca en la cola de Listos. –

Bloqueo

Cuando un hilo necesita esperar por un evento se bloquea, almacenando los registros de usuario, contador de programa y punteros de pila. El procesador puede pasar a ejecutar otro hilo en estado Listo, dentro del mismo proceso o en otro diferente. –

Desbloqueo

Cuando sucede el evento por el que el hilo está bloqueado, el hilo se pasa a la cola de Listos. –

Finalización

Cuando se completa un hilo, se liberan su registro de contexto y pilas. 

Sincronización de hilos

Todos los hilos de un proceso comparten el mismo espacio de direcciones y otros recursos, como por ejemplo, los archivos abiertos. Cualquier alteración de un recurso por cualquiera de los hilos, afecta al entorno del resto de los hilos del mismo proceso. Por tanto, es necesario sincronizar las actividades de los hilos para que no interfieran entre ellos o corrompan estructuras de datos. Por ejemplo, si dos hilos de modo simultáneo intentan añadir un elemento a una lista doblemente enlazada, se podría perder un elemento o la lista podría acabar malformada.

Concurrencia

Desde un punto de vista formal, la concurrencia no se refiere a dos o más eventos que ocurren a la vez sino a dos o más eventos cuyo orden es no determinista, esto es, eventos acerca de los cuales no se puede predecir el orden relativo en que ocurrirán. Si bien dos procesos (o también dos hilos) completamente independientes entre sí ejecutándose simultáneamente son dos procesos concurrentes, la concurrencia se ocupa principalmente de procesos cuya ejecución está vinculada de alguna manera (p. Ej.: dos procesos que comparten cierta información o que dependen uno del otro). 

Contextos donde se da la concurrencia:  –

Múltiples aplicaciones

La multiprogramación fue ideada para permitir compartir dinámicamente el tiempo de procesamiento entre varias aplicaciones activas. –

Aplicaciones estructuradas

Como extensión de los principios del diseño modular y de la programación estructurada, algunas aplicaciones pueden ser programadas eficazmente como un conjunto de procesos concurrentes. –

Estructura del sistema operativo

Las mismas ventajas constructivas son aplicables a la programación de sistemas y, de hecho, los sistemas operativos son a menudo implementados en sí mismos como un conjunto de procesos o hilos. 

Conceptos inherentes a la concurrencia: –

Sección crítica (critical section):

 Sección de código dentro de un proceso que requiere acceso a recursos  compartidos y que no puede ser ejecutada mientras otro proceso esté en una sección de código correspondiente. –

Interbloqueo (deadlock):

Situación en la cual dos o más procesos son incapaces de actuar porque cada uno está esperando que alguno de los otros haga algo. –

Círculo vicioso (livelock):

Situación en la cual dos o más procesos cambian continuamente su estado en respuesta a cambios en los otros procesos, sin realizar ningún trabajo útil. –

Exclusión mutua (mutual exclusión):

Requisito de que cuando un proceso esté en una sección crítica que accede a recursos compartidos, ningún otro proceso pueda estar en una sección crítica que acceda a ninguno de esos recursos compartidos. –

Condición de carrera (race condition):

 Situación en la cual múltiples hilos o procesos leen y escriben un dato compartido y el resultado final depende de la coordinación relativa de sus ejecuciones. –

Inanición (starvation):

Situación en la cual un proceso preparado para avanzar es soslayado indefinidamente por el planificador; aunque es capaz de avanzar, nunca se le escoge. 

Tipos de concurrencia: –

Concurrencia aparente, cuando el número de procesos sea mayor que el de procesadores disponibles. –
Concurrencia real cuando haya un proceso por procesador.

Tipos de Procesos Concurrentes. –

Procesos independientes, son aquellos que se ejecuta sin requerir la ayuda o cooperación de otros procesos. (ej.: intérpretes de comandos). –

Procesos cooperantes,

Son los que están diseñados para trabajar conjuntamente en alguna actividad, para lo que deben ser capaces de comunicarse e interactuar entre ellos. 

Tipos de interacciones entre procesos: –

Comparten o compiten por el acceso a recursos físicos o lógicos. (ej.: 2 procesos totalmente independientes pueden competir por el acceso a disco). –
Comunicación y sincronización entre sí para alcanzar un objetivo común, (ej.: los procesos compilador y ensamblador son dos procesos que deben comunicarse y sincronizarse). 

Causas de la competencia. –

Existencia de recursos compartidos. –Variables globales, regiones de Memoria Principal, Archivos, etc. Pueden ser accedidos por diferentes procesos en un determinado momento. –El procesador es un recurso compartido que también se gestiona (esta labor la realiza el dispatcher, según la política de planificación establecida). –Los dispositivos de E/S son recursos compartidos cuyo uso también debe ser controlado y sincronizado. –Forma en la que los procesos Colaboran o Compiten entre sí: —

Procesos que no se perciben entre sí

Son procesos independientes que no se pretende que trabajen juntos. El mejor ejemplo de esta situación es la multiprogramación de múltiples procesos independientes. Estos bien pueden ser trabajos por lotes o bien sesiones interactivas o una mezcla. Aunque los procesos no estén trabajando juntos, el sistema operativo necesita preocuparse de la competencia por recursos. Por ejemplo, dos aplicaciones independientes pueden querer ambas acceder al mismo disco, fichero o impresora. El sistema operativo debe regular estos accesos. —

Procesos que se perciben indirectamente entre sí

Son procesos que no están necesariamente al tanto de la presencia de los demás mediante sus respectivos ID de proceso, pero que comparten accesos a algún objeto, como un buffer de E/S. Tales procesos exhiben cooperación en la compartición del objeto común. —

Procesos que se perciben directamente entre sí

Son procesos capaces de comunicarse entre sí vía el ID del proceso y que son diseñados para trabajar conjuntamente en cierta actividad. De nuevo, tales procesos exhiben cooperación
. 

Requisitos para la exclusión mutua:

Cualquier mecanismo o técnica que vaya a proporcionar exclusión mutua debería cumplimentar los siguientes requisitos: 1. La exclusión mutua debe hacerse cumplir: sólo se permite un proceso al tiempo dentro de su sección crítica, de entre todos los procesos que tienen secciones críticas para el mismo recurso u objeto compartido. 2. Un proceso que se pare en su sección no crítica debe hacerlo sin interferir con otros procesos. 3. No debe ser posible que un proceso que solicite acceso a una sección crítica sea postergado indefinidamente: ni interbloqueo ni inanición. 4. Cuando ningún proceso esté en una sección crítica, a cualquier proceso que solicite entrar en su sección crítica debe permitírsele entrar sin demora. 5. No se hacen suposiciones sobre las velocidades relativas de los procesos ni sobre el número de procesadores. 6. Un proceso permanece dentro de su sección crítica sólo por un tiempo finito. 

Atomicidad

Operación que requiere la garantía de que se ejecutará como una sola unidad de ejecución, o fallará completamente, sin resultados o estados parciales observables por otros procesos o el entorno. Esto no necesariamente implica que el sistema no retirará el flujo de ejecución en medio de la operación, sino que el efecto de que se le retire el flujo no llevará a comportamiento inconsistente. 

Semáforos

Dos o más procesos pueden cooperar por medio de simples señales, tales que un proceso pueda ser obligado a parar en un lugar específico hasta que haya recibido una señal específica. Cualquier requisito complejo de coordinación puede ser satisfecho con la estructura de señales apropiada. Para la señalización, se utilizan unas variables especiales llamadas semáforos. Para transmitir una señal vía el semáforo s, el proceso ejecutará la primitiva semSignal(s). Para recibir una señal vía el semáforo s, el proceso ejecutará la primitiva semWait(s); si la correspondiente señal no se ha transmitido todavía, el proceso se suspenderá hasta que la transmisión tenga lugar.  1. Un semáforo puede ser inicializado a un valor no negativo. 2. La operación semWait decrementa el valor del semáforo. Si el valor pasa a ser negativo, entonces el proceso que está ejecutando semWait se bloquea. En otro caso, el proceso continúa su ejecución. 3. La operación semSignal incrementa el valor del semáforo. Si el valor es menor o igual que cero, entonces se desbloquea uno de los procesos bloqueados en la operación semWait. Aparte de estas tres operaciones no hay manera de inspeccionar o manipular un semáforo.  Las primitivas semWait y semSignal se asumen atómicas. Una versión más restringida, conocida como semáforo binario o mutex.
Un semáforo binario sólo puede tomar los valores 0 y 1 y se puede definir por las siguientes tres operaciones: Un semáforo binario puede ser inicializado a 0 o 1.  La operación semWaitB comprueba el valor del semáforo. Si el valor es cero, entonces el proceso que está ejecutando semWaitB se bloquea. Si el valor es uno, entonces se cambia el valor a cero y el proceso continúa su ejecución. La operación semSignalB comprueba si hay algún proceso bloqueado en el semáforo. Si lo hay, entonces se desbloquea uno de los procesos bloqueados en la operación semWaitB. Si no hay procesos bloqueados, entonces el valor del semáforo se pone a uno. 

El problema de la sección crítica: –

Funcionamiento básico del mecanismo para proteger el código de la sección critica: –Cada proceso debe solicitar permiso para entrar en su sección crítica, mediante algún fragmento de código que se denomina de forma genérica entrada en la sección crítica
. –Cuando un proceso sale de su sección critica debe indicarlo mediante otro fragmento de código que se denomina salida de la sección crítica
. –Este mecanismo, habilita a otro proceso a ingresar en su sección crítica. La estructura general, por tanto, de cualquier mecanismo que pretenda resolver el problema de la sección critica es la siguiente: Cualquier solución que se utilice para resolver este problema debe cumplir los tres requisitos siguientes: –

Exclusión mutua:

si un proceso está ejecutando código de la sección crítica, ningún otro proceso lo podrá hacer. –

Progreso:

si ningún proceso se está ejecutando dentro de la sección crítica, la decisión de qué proceso entra en la sección se hará sobre los procesos que desean entrar. –

Espera acotada:

debe haber un límite en el número de veces que se permite que los demás procesos entren a ejecutar código de la sección crítica después de que un proceso haya efectuado una solicitud de entrada y antes de que se la conceda. –La espera podrá ser ocupada o bloqueado (Dormir y Despertar). 

Problema del productor-consumidor . –

Es uno de los problemas más habituales que surge cuando se programan aplicaciones utilizando procesos concurrentes. –En este tipo de problemas uno o más procesos, denominados productores, generan datos que son utilizados por otros procesos que denominados consumidores.  En esta clase de problemas es necesario disponer de algún mecanismo de comunicación que permita a los procesos productor y consumidor intercambiar información.

Ambos procesos, además, deben sincronizar su acceso al mecanismo de comunicación para que la interacción entre ellos no sea problemática: –cuando el mecanismo de comunicación se llene, el proceso productor se deberá quedar bloqueado hasta que haya hueco para seguir insertando elementos. –A su vez, el proceso consumidor deberá quedarse bloqueado cuando el mecanismo de comunicación este vacío, ya que en este caso no podrá continuar su ejecución al no disponer de información a consumir. Por tanto, este tipo de problema requiere: –Servicios para que los procesos puedan comunicarse. –Servicios para que se sincronicen al momento de acceder al mecanismo de comunicación. 

Problema de los lectores y escritores:

Existe un determinado objeto, que puede ser un archivo, un registro dentro de un archivo, etc., que va a ser utilizado y compartido por una serie de procesos concurrentes. –Algunos procesos sólo van a acceder al objeto sin modificarlo, (lectores). Para esto se deben seguir una serie de restricciones: 1. No puede acceder al objeto más de un escritor por vez. 2. Mientras el escritor esté accediendo al objeto, ningún otro proceso lector ni escritor podrá acceder a él. 3. Se permite, que múltiples lectores tengan acceso al objeto, ya que ellos nunca van a modificar el contenido del mismo. – Mientras que otros van a acceder al objeto para modificar su contenido (escritores). Por ello es necesario disponer de servicios de sincronización que permitan a los procesos lectores y escritores sincronizarse adecuadamente en el acceso al objeto. 

Comunicación cliente-servidor. –

Los procesos llamados servidores ofrecen una serie de servicios a otros procesos que se denominan clientes
. –El proceso servidor puede residir en la misma máquina que el cliente o en una distinta, en cuyo caso la comunicación deberá realizarse a través de una red de interconexión. – Muchas aplicaciones y servicios de red, como el correo electrónico y la transferencia de archivos, se basan en este modelo. – En este tipo de aplicaciones es necesario que el SO ofrezca servicios que permitan comunicarse a los procesos cliente y servidor, Cuando los procesos ejecutan en la misma máquina, se pueden emplear técnicas basadas en memoria compartida o archivos
. –Este modelo de comunicación suele emplearse en aplicaciones que ejecutan en computadoras que no comparten memoria y en este caso se usan técnicas basadas en paso de mensajes
.

Mecanismos de comunicación

Los mecanismos de comunicación hacen posible que los procesos intercambien datos entre ellos. Los principales mecanismos de comunicación que ofrecen los SO son los siguientes:  Archivos. Tuberías (Pipe-Line). Variables en memoria compartidas. Paso de mensajes. 

Problemas de sincronización

En los problemas de sincronización, un proceso debe esperar la ocurrencia de un determinado evento. Ej.: en problemas de tipo productor-consumidor el proceso consumidor debe esperar mientras no haya datos que consumir. Para que los procesos puedan sincronizarse es necesario disponer de servicios que permitan bloquear o suspender bajo determinadas circunstancias la ejecución de un proceso. Los principales mecanismos de sincronización que ofrecen los sistemas operativos son: Semáforos. Tuberías. Mutex. Futex (Mutex a nivel usuario “Fast User Mutex”). Paso de mensajes. Programas Monitores. 

Comunicación mediante archivos

Un archivo es un mecanismo que puede emplearse para comunicar procesos Ej.: un proceso puede escribir datos en un archivo y otro puede leerlos. Ventajas: –Permite comunicar a un número potencialmente ilimitado de procesos. (los procesos deben tener permisos para acceder a los datos almacenados en un archivo). –Los servidores de archivos ofrecen servicios sencillos y fáciles de utilizar. Desventajas: –Es poco eficiente, puesto que la escritura y lectura en disco es lenta. –Necesitan algún otro mecanismo que permita que los procesos se sincronicen en el acceso a los datos almacenados en un archivo. 

Tuberías (Pipe-Line’s). –

Una tubería es un mecanismo de comunicación y sincronización. –Desde el punto de vista de su utilización, es como un pseudo archivo mantenido en memoria por el SO. –Cada proceso ve la tubería como un conducto, uno de los extremos se utiliza para escribir o insertar datos y el otro para extraer o leer datos. –La escritura se realiza mediante el servicio que se utiliza para escribir datos en un archivo. –La lectura se lleva a cabo mediante el servicio que se emplea para leer de un archivo. –El flujo de datos en la comunicación empleando tuberías es unidireccional y FIFO (First Input First Output), los datos se extraen de la tubería (mediante la operación de lectura) en el mismo orden en el que se insertaron (mediante la operación de escritura). Una tubería es un mecanismo de comunicación con almacenamiento.
El tamaño de una tubería varía en cada SO, típicamente 4 KB. Sobre una tubería puede haber múltiples procesos lectores y escritores
. Se implementan normalmente como regiones de memoria compartida entre los procesos que la utilizan. 
Semántica de las operaciones de lectura y escritura sobre una tubería: Escritura en una tubería (Orden de ingreso de datos FIFO): 1. Si se encuentra llena o se llena durante la escritura, la operación bloquea al proceso escritor hasta que se pueda completar. 2. Si la tubería abierta no encuentra ningún proceso de lectura activo, la operación devuelve el correspondiente error. 3. Si dos procesos intentan escribir de forma simultánea en una tubería, sólo uno de ellos lo hará. El otro se bloquea hasta que finalice la primera escritura. 

Lectura de una tubería

(El procesos extrae los datos de la tubería) 1. Si la tubería está vacía, la llamada bloquea al proceso en la operación de lectura hasta que algún proceso escriba datos en la misma. 2. Si la tubería almacena M bytes y se quieren leer n bytes, entonces: – Si M ≥ n, la llamada devuelve n bytes y elimina de la tubería los datos solicitados. – Si M < n, la llamada devuelve M bytes y elimina los datos disponibles en la tubería. –Si no hay escritores y la tubería está vacía, la operación devuelve fin de archivo EOF (no se bloquea al proceso lector). –Si dos procesos intentan leer de forma simultánea en una tubería, sólo uno de ellos lo hará. El otro se bloquea hasta que finalice la primera lectura. Como puede apreciarse, una lectura de una tubería nunca bloquea al proceso si hay datos disponibles en la misma. 

Existen dos tipos de tuberías: –

Sin nombre, solamente se puede utilizar entre los procesos que desciendan del proceso que creó la tubería. –
Con nombre se puede utilizar para comunicar y sincronizar procesos independientes. –
Nombre local, comunica y sincroniza procesos que residan dentro de la misma máquina. –
Nombre de red, comunica y sincroniza procesos que se ejecutan en distintos equipos. 

Ejecución de comandos con tuberías. –

El uso mas extendido de las tuberías se encuentra en la ejecución de comandos. –De esta forma, se pueden conectar programas sencillos para realizar una tarea más compleja. –Ejemplo: en UNIX si se desea contabilizar el número de usuarios que están conectados al sistema en un instante determinado. Se puede realizar ejecutando el mandato –

Ps aux | grep uade

Con el comando anterior se crean dos procesos que se comunican entre sí mediante una tubería. La ejecución de comandos con tuberías forma parte de la clase de problemas de tipo productor-consumidor.

Se usa el signo | (pipe, tubería) Ej.: en DOS si se desea enviar el resultado del comando “DIR” a la pantalla, pero deteniéndose la presentación cuando se completa la pantalla. Se puede realizar ejecutando el mandato dir | more –
Con el comando anterior se crean dos procesos que se comunican entre sí mediante una tubería. –Un proceso ejecuta el comando dir y otro ejecuta el filtro more, los datos entre procesos se enviaron por una tubería.

Sincronización mediante señales

Por medio de este mecanismo se consigue que unos procesos esperen (se bloqueen) a que se cumpla una determinada condición y que otros los despierten cuando se cumple la condición que les permite continuar su ejecución, de esta manera se pueden sincronizar procesos. El empleo de señales, sin embargo, no es un mecanismo muy apropiado para sincronizar procesos debido a las siguiente razones: 1. Las señales tienen un comportamiento asíncrono
. Un proceso puede recibir una señal en cualquier punto de su ejecución, aunque no esté esperando su recepción. 2. Las señales no se encolan, si hay una señal pendiente de entrega a un proceso y se recibe una señal del mismo tipo, la primera se perderá. Sólo se entregará la última. Esto hace que se puedan perder eventos de sincronización importantes. 

Sección Crítica con semáforos

Para resolver el problema de la sección crítica utilizando semáforos debemos proteger el código que constituye la sección crítica de la siguiente forma: 
wait (s); Sección crítica; 
 signal(s); El valor que tiene que tomar el semáforo inicialmente es 1, de esta forma solo se permite a un único proceso acceder a la sección crítica.  –Si el valor inicial del semáforo fuera, por ejemplo, 2, entonces dos procesos podrían ejecutar la llamada wait sin bloquearse y por tanto se permitiría que ambos ejecutaran de forma simultánea dentro de la sección crítica. –En la figura se representa la ejecución de tres procesos (P0, P1 y P2) que intentan acceder a una sección crítica. Los tres procesos se sincronizan utilizando un semáforo con valor inicial 1. 

Productor/Consumidor con semáforos

Una forma es utilizar un almacén o buffer circular compartido por ambos procesos. –El proceso productor fabrica un determinado dato y lo inserta en un buffer. – El proceso consumidor retira del buffer los elementos insertados por el productor. En general el buffer tiene un tamaño limitado, se dice que el problema es de tipo productor- consumidor con buffer circular y acotado. 
En este tipo de problemas es necesario evitar que ocurra alguna de las siguientes situaciones: – El consumidor saca elementos cuando el buffer está vacío. – El productor coloca elementos en el buffer cuando éste se encuentra lleno. –El productor sobrescribe un elemento que todavía no ha sido sacado del buffer. – El consumidor saca elementos del buffer que ya fueron sacados con anterioridad, –El consumidor saca un elemento mientras el productor lo está insertando. En este problema existen dos tipos de recursos: –los elementos situados en el buffer y los huecos donde situar nuevos elementos. Cada uno de estos recursos se representa mediante un semáforo. Cuando un proceso necesita un recurso de un cierto tipo, decrementa el semáforo correspondiente mediante una operación wait.
Cuando el proceso libera el recurso, se incrementa el semáforo adecuado mediante la operación signal.
Los semáforos utilizados para representar estos dos recursos se denominarán huecos y elementos.
Los valores iniciales de estos dos semáforos coincidirán con el número de recursos que estén disponibles inicialmente, huecos y elementos respectivamente. 

Memoria compartida

La memoria compartida permite comunicar procesos que ejecutan en la misma máquina, bien sea un monoprocesador o un multiprocesador. Con este modelo de comunicación un proceso almacena un valor en una determinada variable, y otro proceso puede acceder a ese valor sin más que consultar la variable. Los threads (procesos ligeros, hilos) que se crean dentro de un proceso comparten memoria de forma natural, y utilizan ésta como mecanismo de comunicación. En los procesos cuando se quiere emplear memoria compartida es necesario recurrir a servicios del SO que permitan que los procesos que se quieren comunicar creen un segmento de memoria compartida al que ambos pueden acceder a través de posiciones de memoria situadas dentro de su espacio de direcciones. 

Mutex y variables condicionales. –

Son mecanismos especialmente concebidos para la sincronización de threads (procesos ligeros). – Un mutex es el mecanismo de sincronización de threads más sencillo y eficiente. –Los mutex se emplean para obtener acceso exclusivo a recursos compartidos y para asegurar la exclusión mutua sobre secciones críticas. Sobre un mutex se pueden realizar dos operaciones básicas: 1.

Lock:

intenta bloquear el mutex.
Si el mutex ya está bloqueado por otro proceso, el proceso que realiza la operación se bloquea. En caso contrario se bloquea el mutex sin bloquear al proceso. 2.

Unlock:

desbloquea el mutex.
Si existen procesos bloqueados en él, se desbloqueará a uno de ellos, que será el nuevo proceso que adquiera el mutex. La operación unlock sobre un mutex debe ejecutarla el thread que adquiríó con anterioridad el mutex mediante la operación lock. Esto es diferente a lo que ocurre con las operaciones wait y signal sobre un semáforo.
Variable condicional, es una variable de sincronización asociada a un mutex que se utiliza para bloquear a un proceso hasta que ocurra algún suceso. Las variables condicionales tienen dos operaciones para esperar y señalizar: –

C_wait:

bloquea al proceso que ejecuta la llamada y lo expulsa del mutex dentro del cual se ejecuta y al que está asociado la variable condicional, permitiendo que algún otro proceso adquiera el mutex. El bloqueo del proceso y la liberación del mutex se realiza de forma atómica. –

C_signal:

desbloquea a uno o varios procesos suspendidos en la variable condicional. El proceso que se despierta compite de nuevo por el mutex. 

Paso de mensajes

Comunica y sincroniza procesos en máquinas distintas. Los procesos intercambian mensajes entre ellos. (Pueden usarse en la misma máquina). No es necesario recurrir a variables compartidas, únicamente debe existir un enlace de comunicación. La comunicación consta de dos operaciones básicas: 1.

Send (destino, mensaje):

envía un mensaje al proceso destino. 2.

Receive (origen, mensaje):

recibe un mensaje del proceso origen. . Las tuberías se pueden considerar como un mecanismo de comunicación basado en paso de mensajes. Aspectos de diseño relativos a los sistemas por paso de mensajes: –
Tamaño del mensaje, Los mensajes que envía un proceso a otro pueden ser de tamaño fijo o tamaño variable. En mensajes de longitud fija la implementación del sistema de paso de mensajes es mas sencilla. –
Flujo de datos, De acuerdo al flujo de datos la comunicación puede ser unidireccional o bidireccional. –
Nombrado, Los procesos que utilizan mensajes para comunicarse o sincronizarse deben tener alguna forma de referirse unos a otros. –La comunicación puede ser directa o indirecta
. –
Directa cuando cada proceso que desea enviar o recibir un mensaje de otro debe nombrar de forma explícita al receptor o emisor del mensaje. —
send(P, mensaje): envía un mensaje al proceso P. —
receive (Q, mensaje): espera la recepción de un mensaje por parte del proceso Q. Existen modalidades con comunicación directa que permiten al receptor recibir un mensaje de cualquier proceso. —
receive(ANY, mensaje).

–
Indirecta es cuando los mensajes pasan por colas de mensajes o puertos. Una cola de mensajes es una estructura a la que los procesos pueden enviar mensajes y de la que se pueden extraer mensajes. —Cuando dos procesos quieren comunicarse entre ellos, el emisor sitúa el mensaje en la cola y el receptor lo extrae de ella. —Sobre una cola de mensajes puede haber múltiples emisores y receptores. —Un puerto es una estructura similar a una cola de mensajes, pero se encuentra asociado a un proceso. En este caso, cuando dos procesos quieren comunicarse entre si, el receptor crea un puerto y el emisor envía mensajes al puerto del receptor. 

Send(Q, mensaje):

envía un mensaje a la cola o al puerto Q.

Receive (Q, mensaje):

recibe un mensaje de la cola o del puerto Q. Cualquiera que sea el método utilizado, el paso de mensajes siempre se realiza en exclusión mutua.

Sincronización:

La comunicación entre dos procesos es síncrona cuando los dos procesos han de ejecutar los servicios de comunicación al mismo tiempo, es decir, el emisor debe estar ejecutando la operación send y el receptor ha de estar ejecutando la operación receive. La comunicación es asíncrona en caso contrario. Combinaciones más habituales que implementan los distintos tipos de paso de mensajes. –

Envío y recepción bloqueante

En este caso, tanto el emisor como el receptor se bloquean hasta que tenga lugar la entrega del mensaje. Ésta es una técnica de paso de mensajes totalmente síncrona que se conoce como cita. –

Envió no bloqueante y recepción bloqueante

Ésta es la combinación generalmente mas utilizada. El emisor no se bloquea hasta que tenga lugar la recepción y por tanto puede continuar su ejecución. El proceso que espera el mensaje, sin embargo, se bloquea hasta que llega. –

Envío y recepción no bloqueante

Se corresponde con una comunicación totalmente asíncrona en la que nadie debe esperar. En este tipo de comunicación es necesario disponer servicios que permitan al receptor saber si se ha recibido un mensaje. –

Almacenamiento:

El enlace y por tanto el paso de mensajes pueden: –
No tener capacidad (sin almacenamiento) para almacenar mensajes. La comunicación entre los procesos emisor y receptor debe ser síncrona. –
Tener capacidad (con almacenamiento) para almacenar mensajes. En este caso, la cola de mensajes o el puerto al que se envían los mensajes pueden tener un cierto tamaño para almacenar mensajes a la espera de su recepción.