Recordando

Comunicacin entre Procesos Condiciones de Competencia Regin Crtica Exclusin Mutua

Inhabilitacin de interrupciones Variables de bloqueo Alternancia Estricta Solucin de Dekker Solucin de Peterson TSL

Activar y Desactivar
Peterson y TSL soluciones correctas, pero con espera activa. Prdida de tiempo en CPU, y efectos inesperados, como Problema de inversin de prioridad.

Sleep - wakeup
En vez de utilizar espera activa, se utilizan primitivas de comunicacin entre procesos que se bloquean, (sleep y wakeup). sleep es una llamada al sistema que hace que el invocador se bloquee, hasta que otro proceso lo active, con la llamada al sistema wakeup.

Productor Consumidor (buffer acotado o buffer limitado)

Dos procesos comparten un buffer de tamao limitado. Uno de ellos, el productor coloca datos en el buffer. El otro el consumidor, saca los datos depositados por el productor.
Si no hay datos en el buffer, el consumidor no puede extraer elementos de la zona compartida. El proceso consumidor debe esperar hasta que el productor deposite datos en el buffer. Si no hay espacio en el buffer, el productor no puede introducir elementos en la zona compartida. Debe esperar hasta que el consumidor extraiga datos del buffer. El buffer es un elemento compartido por los dos procesos y ambos modifican el estado de aquel cada vez que acceden a el. El acceso al buffer se har en exclusin mutua.

Problema del Algoritmo

El acceso a la variable cuenta no est restringido. Si el buffer est vaco y el consumidor lee cuenta y ve que es 0, si en ese momento el calendarizador deja de ejecutar consumidor y ejecuta productor, ste inserta un elemento y cuenta ahora es 1. Manda wakeup para activar consumidor, pero esta seal se pierde porque conumidor no estaba inactivo. Consumidor entra y se desactiva por que cree que cuenta es 0. Y productor llena el buffer y se desactiva. Ambos quedan inactivos.

Semforos
Un semforo es una variable entera sobre la que se pueden realizar tres operaciones atmicas 1.- Asignacin de valores no negativos 2.- Wait o P o espera.- Comprueba que el valor del semforo es mayor que 0; si es as, decrementa el valor y contina. Si el valor es 0 el proceso se bloquea. 3.- signal o V o seal. Incrementa en una unidad el valor del semforo. Si hay algn proceso bloqueado en este semforo, se despierta a unos de los procesos.

Tipos de Semforos
Hay dos tipos de semforos. Binarios.- Solo pueden tomar el valor de 0 o 1. Generales.- 0 o cualquier valor positivo.

Generalmente utilizan una cola FIFO.

Productor consumidor con semforos

Se utilizan tres semforos; uno llamado llenas, para contar el nmero de ranuras ocupadas, otro llamada vacas, para contar el nmero de ranuras desocupadas, y el ltimo llamado mutex, para asegurar que el productor y el consumidor no tengan acceso al buffer al mismo tiempo. (ver algoritmo)

Mutexes
Versin simplificada del semforo, para administrar la exclusin mutua respecto a algn recurso o fragmento de cdigo compartido. Se utiliza mas en hilos (en espacio de usuario). Es una variable con 2 estados posibles (bloqueado o desbloqueado). Basta un bit para representarlo. (Ver algoritmo)

Mutexes
La diferencia con entrar_region en la instruccin TSL es que al invovar mutex_lock, si est ocupada la regin crtica, invoca a thread_yield, para ceder la CPU a otro proceso, en lugar de realizar una espera activa.

Monitores
Los monitores son estructuras de un lenguaje de programacin que ofrecen una funcionalidad equivalente a las de los semforos pero son ms fciles de controlar. La estructura de monitor se ha implementado en varios lenguajes de programacin como: Pascal concurrente, Modulo-2, Java, etc. En concreto, para una lista enlazada se puede necesitar un cierre que bloquee todas las listas enlazadas o bien un cierre por cada elemento de una lista.

Monitores con Seales: ( definicin de Hoare )

Un monitor es un modulo de software que consta de uno o ms procedimientos, una secuencia de inicio y uno datos locales. Sus caractersticas son las siguientes:
Solo los procedimientos del monitor acceden a variables de datos locales. Un proceso entra en el monitor invocando a uno de sus procedimientos. En el monitor solo un proceso puede ser ejecutado en un momento dado; cualquier otro proceso quedara suspendido esperando la disponibilidad del monitor.

Al ser un proceso por vez, el monitor puede ofrecer un servicio de exclusin mutua fcilmente. As una estructura de datos puede protegerse situndola dentro de un monitor.

Monitores con seales

Al ser un proceso por vez, el monitor puede ofrecer un servicio de exclusin mutua fcilmente. As una estructura de datos puede protegerse situndola dentro de un monitor. Los monitores deben ofrecer herramientas de sincronizacin. Por ejemplo: si un proceso llama a un monitor y una vez dentro de l el proceso queda suspendido esperando alguna condicin, har falta un servicio que libere al monitor y lo deje disponible para el siguiente proceso. Mas tarde cuando la condicin se cumpla el proceso suspendido podr regresar al monitor y ejecutarse desde el momento de la suspensin.

Monitores con seales

Hay dos funciones para operar variables de condicin:
cwait (c): suspende la ejecucin del proceso que llama bajo la condicin "c". El monitor est ahora disponible para otro proceso. csignal (c): retorna la ejecucin de un proceso suspendido despus de un cwait, bajo la misma condicin. Si hay varios procesos elige uno de ellos.

Monitor con seales

Aunque un proceso puede entrar al monitor llamando a cualquiera de sus procedimientos, se puede decir que el monitor tiene un solo punto de acceso, custodiado para que solo un proceso este en el monitor en un instante dado. Si existen otros procesos tratando de entrar al monitor, estos se colocan en una cola de procesos suspendidos esperando la disponibilidad del monitor. Un proceso dentro de un monitor puede suspenderse a s mismo, temporalmente, bajo la condicin X ejecutando cwait(x), entonces se coloca en una cola de procesos que esperan que cambie la condicin X entonces ejecuta un csignal(x) que avisa a la cola de condicin correspondiente de que la condicin a cambiado.

Monitor con seales

Problema del productor consumidor con monitor con seales Ver algoritmo

Monitores con Notificacin y Difusin (definicin de Lampson y Redell)

Son varios los inconvenientes que presenta la solucin de Hoare: -Si el proceso que ejecuta el csignal( ) no ha terminado en el monitor, se necesitaran dos cambios de procesos adicionales: uno para suspender el proceso y otro para reanudarlo. -La planificacin de procesos asociados con las seales debe ser muy fiable. Si un proceso ejecuta un csignal ( ), el proceso de la cola de condicin correspondiente debe activarse de inmediato, antes de que ingrese otro proceso del exterior o cambie la condicin bajo la que se activ el proceso. Otro caso seria que un proceso productor escribe un carcter en el buffer y falla antes de dar la seal, entonces la cola de condicin no-vaca se colgara para siempre.

Monitores con Notificacin y Difusin

Lampson y Redell desarrollaron una definicin de monitores para el lenguaje MESA [Lamp 80]. La estructura de mesa reemplaza la primitiva csignal( ) por cnotify( ). Cuando un proceso ejecuta cnotify(x) enva una notificacin a la cola de condicin X, lo cual no significa que el proceso que esta ocupando el monitor vaya a detenerse, simplemente el cnotify(x) avisa al proceso de la cola de condicin correspondiente de que ser reanudado en un futuro cercano. Puesto que esta no garantiza que un proceso exterior entre al monitor, el proceso debe comprobar la condicin nuevamente. En el cdigo, la sentencia IF se reemplaza por un bucle While, lo cual genera una evaluacin extra de la variable, pero sin embargo no hay cambios de procesos extra.

Monitores con Notificacin y Difusin

Una modificacin til seria asociar un temporizador de guardia a cnotify( ) que permitira que un proceso que ha esperado durante el intervalo mximo sea situado en estado de listo, independientemente de s se ha notificado la condicin. Con la norma de notificar a los procesos en lugar de reactivarlos, es posible aadir una primitiva de difusin cbroadcast. La difusin provoca que todos los procesos que estn esperando por una condicin se coloquen en el estado de listo. Esto es til cuando un proceso no sabe cuantos procesos deben reactivarse. El mtodo Lampson/Redell es menos propenso a errores debido a que cada procedimiento comprueba la condicin luego de ser despertado, por medio de la instruccin while, un proceso puede realizar una seal o una difusin incorrectamente sin provocar un error en el programa que la recibe.

Monitores con Notificacin y Difusin

Adems este modelo presta un mtodo mas modular de construccin de programas. Hay dos niveles de condicin que deben satisfacerse para los procesos secuenciales cooperantes.
1.- Estructura de datos consistentes: significa que el monitor hace cumplir la exclusin mutua y concluye la operacin de entrada o salida antes de permitir cualquier otra operacin sobre el buffer. 2.- La misma condicin del nivel 1 y, adems disponer de suficiente memoria para que este proceso pueda completar su solicitud de asignacin.

Paso de Mensajes
Son 2 los requisitos bsicos que deben satisfacerse cuando los procesos interactan entre si. Ellos son:
La sincronizacin La comunicacin

Los procesos tienen que sincronizarse para cumplir la exclusin mutua, los procesos cooperantes pueden necesitar intercambiar informacin. El paso de mensajes es un mtodo que permite que se realice ambas funciones. Este mtodo tiene la ventaja de que es de fcil implementacin en sistemas distribuidos y tambin en sistemas de multiprocesador y monoprocesador de memoria compartida.

Paso de Mensajes
La funcionalidad real del paso de mensajes, generalmente, se da por medio de un par de primitivas:
send(destino, mensaje) receive(origen, mensaje)

Este es el conjunto mnimo de operaciones necesarias para que los procesos puedan dedicarse al paso de mensajes.

Sincronizacin
La comunicacin de un mensaje entre 2 procesos implica cierto nivel de sincronizacin entre ambos. El receptor no puede recibir un mensaje hasta que sea enviado por otro proceso. Adems hace falta especificar que le sucede a un proceso despus de ejecutar una primitiva SEND o RECEIVE.

Paso de Mensajes
Considrese en primer lugar la primitiva send. Cuando se ejecuta una primitiva send en un proceso, hay 2 posibilidades: o bien el proceso emisor se bloquea hasta que recibe el mensaje o no se bloquea. Igualmente cuando un proceso ejecuta una primitiva RECEIVE, existen 2 opciones: 1) Si previamente se ha enviado algn mensaje, este es recibido y continua la ejecucin. 2) Si no hay ningn mensaje esperando entonces: a) el proceso se bloquea hasta que llega un mensaje o, b) el proceso contina ejecutando, abandonando el intento de recepcin. El emisor y el receptor pueden ser bloqueantes o no bloqueantes.

Paso de Mensajes
Existen 3 tipos de combinaciones pero un sistema solo implementa uno o dos. I) Envo bloqueante, recepcin bloqueante: tanto el emisor como el receptor se bloquean hasta que llega el mensaje; esta tcnica se conoce como rendezvous. II) Envo no bloqueante, recepcin bloqueante: aunque el emisor puede continuar, el receptor se bloquea hasta que llega el mensaje solicitado. Es la combinacin ms til. III) Envo no bloqueante, recepcin no bloqueante: nadie debe esperar.

Paso de Mensajes
El send no bloqueante es la forma ms natural para muchas tareas de programacin concurrente. Un posible riesgo del send no bloquente es que por error puede llevar a una situacin en la que el proceso genere mensajes repetidamente. Para el receive, la versin bloqueante es la mas natural para muchas tareas de programacin concurrente. En general, un proceso que solicita un mensaje necesitara la informacin esperada antes de continuar.

Direccionamiento
Es necesario disponer de alguna forma de especificar en la primitiva send que proceso va a recibir el mensaje. La mayora de las implementaciones permiten a los procesos receptores indicar el origen del mensaje que se va a recibir. Los distintos esquemas para hacer referencia a los procesos en las primitivas send y receive se encuadran dentro de 2 categoras:

Direccionamiento Directo
La primitiva send incluye una identificacin especfica del proceso de destino. La primitiva receive se puede gestionar de 2 formas:
1.- Una posibilidad requiere que el proceso designe explcitamente un proceso emisor. El proceso debe conocer de antemano de que proceso espera un mensaje. 2.- En otros casos es imposible especificar el proceso de origen por anticipado.

Direccionamiento Indirecto
Los mensajes no se envan directamente del emisor al receptor, sino a una estructura de datos compartidos formada por colas, que pueden guardar los mensajes temporalmente, que se denominan BUZONES (mailboxes). Para que 2 procesos se comuniquen, uno enva mensajes al buzn apropiado y el otro los retira. Una ventaja de este tipo de direccionamiento es que se desacopla a emisor y receptor, asegurando mayor flexibilidad en el uso de mensajes.

Barreras
Mecanismo de sincronizacin para mas de un proceso. Algunas aplicaciones se dividen en fases y tienen la regla de que ningn proceso puede pasar a la siguiente fase antes de que todos los procesos estn listos para hacerlo. Este comportamiento puede lograrse colocando una barrera al final de cada fase. Cuando un proceso llega a la barrera, se bloquea hasta que todos los procesos han llegado a ella.

Barreras
Ver algoritmo para problema de relajacin en fsica o ingeniera.

Problemas clsicos de comunicacin entre procesos.

El problemas de la Cena de los Filsofos El problema de Lectores / Escritores El problema del barbero dormiln

CALENDARIZACIN

Despachador - Dispatcher
El S.O. es el encargado de distribuir el uso de la CPU entre los diferentes procesos. Para ello ha de encargarse de:
Conmutar la CPU entre los proceso (repartir el uso de la CPU entre los procesos). Evitar que los procesos puedan modificarse entre s o al S.O.

La parte del SO encargada de entregar la CPU a un proceso se denomina distribuidor o despachador (dispatcher) y constituye el mecanismo utilizado por el CPU para entregar el CPU a otro proceso.

Calendarizador
La decisin acerca del proceso al que se le entregar la CPU representa la poltica de planificacin y la parte del SO que la implementa se le conoce como planificador (calendarizador, scheduler). (El cdigo del despachador se ejecuta desde que inicia el SO, constituye su parte ms interna y est escrito en ensamblador, pues se ejecuta con mucha frecuencia)

Funciones realizadas por el despachador

1. Permitir la ejecucin de un proceso en la CPU durante un intervalo de tiempo (quantum) 2. Guardar el estado de ese proceso en el PCB correspondiente. 3. Restaurar el estado de otro proceso a partir de su PCB 4. Transferir el control al nuevo proceso.

Despachador
El despachador guarda en el PCB del proceso todo aquella informacin que sea necesaria para la reanudacin del proceso. (El contenido de los registros de la CPU, reas de memoria donde se encuentran los datos e instrucciones, etc).

Calendarizador
El Despachador se activa siempre que el calendarizador decide entregar la CPU a otro proceso. El calendarizador puede activarse en las siguientes circunstancias:
1. 2. 3. 4. Cambio de ejecucin a espera. Cambio de ejecucin a preparado. Cambio de espera a preparado. Fin de proceso.

En todas las situaciones el calendarizador podr seleccionar un nuevo proceso para que el despachador le ceda la CPU.

Apropiativa No Apropiativa
Si el calendarizador slo entra en accin cuando un proceso realiza una llamada al sistema o termina, la planificacin recibe el nombre de Planificacin no apropiativa, cooperativa o sin requisa. (Win 3.1 o Mac OS) Si la activacin se produce en todas las situaciones mencionadas, entonces se denomina Planificacin apropiativa, no cooperativa o con requisa. (Unix, Windows XP, VMS)

Algoritmos de Planificacin
El objetivo de la planificacin de CPU consiste en repartir el tiempo de CPU entre los procesos para aumentar el rendimiento, siendo el planificador o el calendarizador el encargado de decidir en que orden se deben atender las solicitudes de uso del procesador por parte de los procesos.

Criterios de Comparacin
Para poder comparar diferentes algoritmos de planificacin se establecen diversos criterios: Rendimiento o productividad.- Numero de tareas procesadas por unidad de tiempo. Tiempo de espera.- Tiempo que el proceso para esperando algn recurso incluido la CPU Tiempo de retorno o estancia.- Tiempo transcurrido desde que el trabajo entra en el sistema hasta que lo abandona.

Criterios de comparacin
Tiempo de Respuesta.- Tiempo tpico de sistemas interactivos, es el tiempo que transcurre desde que el usuario enva una peticin al sistema hasta que comienza a aparecer la respuesta. Grado de sobrecarga.- Fraccin de tiempo de CPU consumida por el dispatcher y el scheduler frente al tiempo total empleada en la ejecucin de los trabajos.

Tiempo de Espera
Los algoritmos de planificacin no afectan la cantidad de tiempo de CPU que necesita un proceso para ejecutarse, as como tampoco afectan al tiempo que se necesita para completar sus operaciones de E/S. Estos algoritmos afectan nicamente a la cantidad de tiempo que el proceso pasa en la cola de procesos preparados, por lo que en muchas ocasiones en lugar de medir el tiempo de retorno se mide el tiempo de espera de cada proceso.

Tipos de Planificadores

Si atendemos a la frecuencia con que se ejecutan los planificadores y al alcance en el tiempo de sus decisiones, podemos clasificarlos en tres tipos: Planificadores a largo plazo Planificadores a mediano plazo Planificadores a corto plazo

Planificadores a largo Plazo

Son tpicos de los sistemas de proceso por lotes. Se encargan de determinar que trabajos, van a ser cargados en memoria para su ejecucin; por lo que determina el grado de multiprogramacin. Su frecuencia de ejecucin es mucho menor que el planificador a corto plazo, ya que solo se activa cuando un proceso finaliza.
Procesos limitados por E/S. La mayor parte de su tiempo de estancia en el sistema se consume en operaciones de E/S. Procesos limitados por CPU. La mayor parte de su tiempo de estancia en el sistema se consume utilizando la CPU.

Planificadores a mediano plazo

Son propios de algunos sistemas interactivos. Su misin principal consiste en reducir el grado de multiprogramacin descargando procesos de la memoria para evitar que decaiga en exceso el rendimiento del sistema. Puede activarse con el fin de mejorar la mezcla de procesos en memoria o cuando se produce un cambio significativo en los requisitos de memoria (por ejemplo, un proceso de alta prioridad pide ms memoria estando el sistema saturado)

Planificadores a corto plazo

Se encargan de seleccionar cul de los procesos cargados en memoria y listos para ser ejecutados obtendr la CPU. Este tipo de planificador se ejecuta con mucha frecuencia.
Con requisa.- Planificacin apropiativa Sin requisa.- Planificacin no apropiativa o cooperativa.

Algoritmos de Planificacin
Algunos de los algoritmos de planificacin mas comunes son: FCFS (First-come, First-served) SPN (Shortest Process Next) SRT SRTF ( Shortest Remaining Time First) Por prioridad Round Robin (circular)

FCFS
Primero en llegar, primero en servirse. En este algoritmo, las peticiones de uso de CPU se atienden en el mismo orden en que ingresan al sistema.
El primer proceso que pide la CPU es al primero que se le entrega. Se implementa tratando la cola de proceso preparados como una estructura FIFO. No apropiativo. Un proceso retiene la CPU hasta que finaliza o solicita una operacin de E/S Sus prestaciones dependen fuertemente del orden de llegada de los procesos y de sus caractersticas.

SPN
Primero el trabajo mas corto. (SJF). Consiste en asociar a cada trabajo la duracin de su tiempo en CPU y asignar a la CPU a aquel que presente el menor tiempo. Si hay varios con igual valor, se aplica FCFS entre ellos.
Si todos los trabajos llegan al sistema al mismo tiempo, este algoritmo minimiza el tiempo medio de espera. Puede producirse inanicin sobre procesos con tiempos de CPU grandes. No conocemos la duracin del siguiente tiempo del CPU.

SRT - SRTF
Shortest Remaining Time First.- Es una variante del SPN. Minimiza an mas los tiempos de retorno en caso de que no todos los trabajos a planificar estn disponibles en el instante inicial. Siempre que ingresa un trabajo, se compara la duracin de su siguiente rfaga frente al tiempo que le queda al proceso en la CPU. As si el nuevo trabajo ofrece una duracin de siguiente rfaga menor que el tiempo de rfaga restante del proceso que est en la CPU, el planificador desaloja al proceso de la CPU y se la cede al nuevo.

Por Prioridad
Tanto SJF como SRTF pueden considerarse como casos particulares de algoritmos de planificacin por prioridad. En este tipo de algoritmos se asocia una prioridad a cada proceso y se cede la CPU al mas prioritario. Las prioridades suelen definirse en base a parmetros internos (como tiempo de CPU consumido) o externos (tipo de usuario o dinero pagado por tiempo de CPU). Puede presentarse inanicin. Para evitarlo se puede variar la prioridad en funcin del tiempo.

Round Robin o Circular

Algoritmo tpico de sistemas compartidos. Se parece a FCFS pero con requisa para evitar que procesos monopolizen la CPU-. Round Robin determina el lapso mximo de tiempo que un proceso puede disponer la CPU al que se denomina quantum, rodaja de tiempo o time slice. -10 ms y 100 ms Se mantiene la cola de procesos preparados como una cola FIFO. El planificador selecciona al primer proceso de la cola y le cede la CPU hasta que se produce alguno de estos eventos:
Fin del proceso Fin del Quantum Solicitud de algun otro recurso (pe, operacin de E/S)

Round Robin o Circular

En los dos ltimos casos, el proceso que abandona la CPU volver a ingresar al final de la cola de procesos preparados. Las prestaciones ofrecidas por el algoritmo dependen de la duracin del quantum, si ste es muy grande entonces Round-Robin degenera a FCFS; si es demasiado pequeo, se perder una parte importante de tiempo de CPU en tareas de planificacin.