CAMILO ANDRES PINTO OVALLE CODIGO: 160002423

Un semforo es una estructura diseada para sincronizar dos o ms threads o procesos, de modo que su ejecucin se realice de forma ordenada y sin conflictos entre ellos. Un semforo nos sirve para poder permitir o restringir a los procesos o hilos el acceso a algn recurso compartido. Un semforo bsico es una estructura formada por una posicin de memoria y dos instrucciones, una para reservarlo y otra para liberarlo. A esto se le puede aadir una cola de threads para recordar el orden en que se hicieron las peticiones.

 Los semforos cuentan con operaciones bsicas, una de ellas es para reservarlo y la otra para liberarlo, wait(espera) y signal(seal) respectivamente, equivalente down y up. Existe una tercera operacin que consiste en inicializar el semforo.

 Decrementaen una unidad el semforo. Bloquea hilo/proceso si el semforo es menor que cero, sino entonces permite a hilo/proceso continuar.

Llamada W(semaforo) o down(semaforo).

 Incrementa semforo en uno y si hay algn proceso/hebra esperando lo despierta. Existe un valor mximo para incrementar el semforo, este no se va a infinito.

 Los semforos pueden ser de 2 tipos: Binarios o Generales (Contadores).

La operacin de inicializador definir si el semforo ser binario o no, es decir, si se inicializa con 1, el semforo ser binario ya que solo podr manejar un recurso compartido, en caso de tener N recursos compartidos se inicializara con N.

 Existen semforos que tienen la operacin de manejar una cola del tipo FIFO (PEPS) para llevar el control de los procesos que estn solicitando los recursos, as cuando se liberen los recursos estos puedan asignarle dicho recurso al primer proceso que lo solicito.

 Los semforos se emplean para permitir el acceso a diferentes partes de programas (llamados secciones criticas) donde se manipulan variables o recursos que deben ser accedidos de forma especial. Segn el valor con que son inicializados se permiten a ms o menos procesos utilizar el recurso de forma simultnea. Un tipo simple de semforo es el binario, que puede tomar solamente los valores 0 y 1. Se inicializan en 1 y son usados cuando slo un proceso puede acceder a un recurso a la vez. Son esencialmente lo mismo que los mutex. Cuando el recurso est disponible, un proceso accede y decrementa el valor del semforo con la operacin P. El valor queda entonces en 0, lo que hace que si otro proceso intenta decrementarlo tenga que esperar. Cuando el proceso que decrement el semforo realiza una operacin V, algn proceso que estaba esperando comienza a utilizar el recurso.

 Los semforos pueden ser usados para diferentes propsitos, entre ellos:

Implementar cierres de exclusion mutua o locks. Barreras. Permitir a un mximo de N threads (hilos) acceder a un recurso, inicializando el semforo en N. Notificacin. Inicializando el semforo en 0 puede usarse para comunicacin entre threads sobre la disponibilidad de un recurso.

 No se puede imponer el uso correcto de los Down y Up No existe una asociacin entre el semforo y el recurso Entre Down y Up el usuario puede realizar cualquier operacin con el recurso.

 Un monitor encapsula el cdigo relativo a un recurso compartido en un solo mdulo de programa Los monitores son estructuras de un lenguaje de programacin que ofrecen una funcionalidad equivalente a la de los semforos y que son ms fciles de controlar. Los monitores fueron propuestos por Brich Hansen y mejorados por Hoare para poder utilizar procesos automticos de sincronizacin.

 Un mdulo monitor encapsula la exclusin mutua de datos y procedimientos que pueden acceder a los datos protegidos. Los usuarios pueden hacer llamadas a estos procedimientos usando al monitor como una tabla de estado para determinar cuando proceder y cuando suspender operaciones.

El concepto de monitor fue definido por primera vez por Charles Antony Richard Hoare en un artculo del ao 1974.
La estructura de los monitores se ha implementado en varios lenguajes de programacin, incluido Pascal concurrente, Modula-2, Modula-3 y Java, y como biblioteca de programas.

 Mantenimiento ms simple. Menos errores de programacin. La interfaz del monitor es un conjunto de funciones que representan las diferentes operaciones que pueden hacerse con el recurso.

Las caractersticas bsicas de un monitor son las siguientes: Las variables de datos locales estn slo accesibles para los procedimientos del monitor y no para procedimientos externos.

Un proceso entra en el monitor invocando a uno de sus procedimientos.

Slo un proceso puede estar ejecutando en el monitor en un instante dado; cualquier otro proceso que haya invocado al monitor quedar suspendido mientras espera que el monitor est disponible.

Un monitor tiene cuatro componentes: inicializacin, datos privados, mtodos del monitor y cola de entrada. Inicializacin: contiene el cdigo a ser ejecutado cuando el monitor es creado.

Datos privados: contiene los procedimientos privados, que slo pueden ser usados desde dentro del monitor y no son visibles desde fuera.
Mtodos del monitor: son los procedimientos que pueden ser llamados desde fuera del monitor. Cola de entrada: contiene a los hilos que han llamado a algn mtodo del monitor pero no han podido adquirir permiso para ejecutarlos an.

En la definicin original de Hoare, el thread que ejecuta cond_signal le cede el monitor al thread que esperaba. El monitor toma entonces el lock y se lo entrega al thread durmiente, que reanuda la ejecucin. Ms tarde cuando el monitor quede libre nuevamente el thread que cedi el lock volver a ejecutar. Ventajas: El thread que reanuda la ejecucin puede hacerlo inmediatamente sin fijarse si la condicin se cumple, porque desde que se ejecut cond_signal hasta que lleg su turno de ejecutar ningn proceso puede cambiarla. El thread despertado ya estaba esperando desde antes, por lo que podra suponerse que es ms urgente ejecutarlo a seguir con el proceso despertante.

Desventajas: Si el proceso que ejecuta cond_signal no termin con su ejecucin se necesitarn dos cambios de contexto para que vuelva a tomar el lock del monitor. Al despertar a un thread que espera en una variable de condicin, se debe asegurar que reanude su ejecucin inmediatamente. De otra forma, algn otro thread podra cambiar la condicin. Esto implica que la planificacin debe ser muy fiable, y dificulta la implementacin.

Butler W. Lampson y David D. Redell en 1980 desarrollaron una definicin diferente de monitores para el lenguaje Mesa que lidia con las desventajas de los monitores de tipo Hoare y aade algunas caractersticas. En los monitores de Lampson y Redell el thread que ejecuta cond_signal sobre una variable de condicin contina con su ejecucin dentro del monitor. Si hay otro thread esperando en esa variable de condicin, se despierta y lo deja como listo. Podr intentar entrar el monitor cuando ste quede libre, aunque puede suceder que otro thread logre entrar antes. Este nuevo thread puede cambiar la condicin por la cual el primer thread estaba durmiendo. Cuando reanude la ejecucin el durmiente, debera verificar que la condicin efectivamente es la que necesita para seguir ejecutando. En el proceso que durmi, por lo tanto, es necesario cambiar la instruccin if por while, para que al despertar compruebe nuevamente la condicin, y de no ser cierta vuelva a llamar a cond_wait.

Los monitores del tipo Mesa son menos propensos a errores, ya que un thread podra hacer una llamada incorrecta a cond_signal o a cond_broadcast sin afectar al thread en espera, que verificar la condicin y seguir durmiendo si no fuera la esperada.