lunes, 14 de noviembre de 2011

2.14 ACCIONES A REALIZAR A ANTE UN INTERBLOQUEO: PREVENCIÒN, DETECCIÒN Y EVITAR

En la política del sistema operativo, deben darse tres condiciones para que pueda producirse un interbloqueo:
1- Condición de exclusión mutua: Cada recurso está asignado a un único proceso o está disponible.
2- Condición de posesión y espera: Los procesos que tienen, en un momento dado, recursos asignados con anterioridad, pueden solicitar nuevos recursos.
3- Condición de no apropiación: Los recursos otorgados con anterioridad no pueden ser forzados a dejar un proceso. El proceso que los posee debe liberarlos en forma explícita.
PREVENCIÓN DEL INTERBLOQUEO
La estrategia básica de la prevención del interbloqueo consiste, a grandes rasgos, en diseñar su sistema de manera que esté excluida, a priori, la posibilidad de interbloqueo.
Los métodos para prevenir el interbloqueo son de dos tipos:
- Los métodos indirectos que consisten en impedir la aparición de alguna de las tres condiciones necesarias para que se de el interbloqueo.
- Los métodos directos que consisten en evitar la aparición del círculo vicioso de espera.
PREDICCIÓN DEL INTERBLOQUEO
Una forma de resolver el problema del interbloqueo, que se diferencia sutilmente de la prevención, es la predicción del interbloqueo. En la prevención de interbloqueo, se obligaba a las solicitudes de recursos a impedir que sucediera, por lo menos, alguna de las cuatro condiciones de interbloqueo. Esto se hace indirectamente, impidiendo la aparición de una de las tres condiciones necesarias (exclusión mutua, retención y espera, no apropiación) o directamente, impidiendo la aparición de un círculo vicioso de espera. Se llega así a un uso ineficiente de los recursos y una ejecución ineficiente de los procesos. Con predicción del interbloqueo, por otro lado, se pueden alcanzar las tres condiciones necesarias, pero se realizan elecciones acertadas para asegurar que nunca se llega al punto de interbloqueo. La predicción, por lo tanto, permite más concurrencia que la prevención. Con predicción del interbloqueo, se decide dinámicamente si la petición actual de asignación de un recurso podría, de concederse, llevar potencialmente a un interbloqueo. La predicción del interbloqueo necesita, por lo tanto, conocer las peticiones futuras de recursos. Enfoques para la predicción del interbloqueo: - - No iniciar un proceso si sus demandas pueden llevar a interbloqueo. - - No conceder una solicitud de incrementar los recursos de un proceso si esta asignación puede llevar a interbloqueo.
- DETECCIÓN DEL INTERBLOQUEO
- Las estrategias de prevención de interbloqueo son muy conservadoras; resuelven el problema limitando el acceso a recursos e imponiendo restricciones sobre los procesos. En cambio, las estrategias de detección de interbloqueo, no limitan el acceso a recursos ni restringen las acciones del proceso. Con la detección del interbloqueo, se concederán los recursos que los procesos necesiten siempre que sea posible. Periódicamente, el S. O. ejecuta un algoritmo que permite detectar la condición de circulo vicioso de espera. - La detección del interbloqueo es el proceso de determinar si realmente existe un interbloqueo e identificar los procesos y recursos implicados en él. Una posibilidad detectar un interbloqueo es monitorear cada cierto tiempo el estado de los recursos. Cada vez que se solicita o se devuelve un recurso, se actualiza el estado de los recursos y se hace una verificación para observar si existe algún ciclo. - Este método está basado en suponer que un interbloqueo no se presente y que los recursos del sistema que han sido asignados, se liberarán en el momento que otro proceso lo requiera.
- Algoritmo de detección del interbloqueo - Una comprobación para interbloqueo puede hacerse con igual o menor frecuencia que cada solicitud de recursos, dependiendo de que tan probable es que ocurra un interbloqueo. Comprobar cada solicitud de recursos tiene dos ventajas: Conduce a la detección temprana y el algoritmo es simple, de manera relativa porque se basa en cambios crecientes al estado del sistema. Además, las comprobaciones frecuentes consumen un tiempo considerable de procesador. - Los algoritmos de detección de bloqueos implican cierta sobrecarga en tiempo de ejecución: - surge el siguiente

RECUPERACIÓN DE INTERBLOQUEO
Cuando se ha detectado que existe un interbloqueo, podemos actuar de varias formas. Una posibilidad es informar al operador que ha ocurrido un interbloqueo y dejar que el operador se ocupe de él manualmente. La otra posibilidad es dejar que el sistema se recupere automáticamente del interbloqueo. Dentro de esta recuperación automática tenemos dos opciones para romper el interbloqueo: Una consiste en abortar uno o más procesos hasta romper la espera circular, y la segunda es apropiar algunos recursos de uno o más de los procesos bloqueados. - La recuperación después de un interbloqueo se complica porque puede no estar claro que el sistema se haya bloqueado. Las mayorías de los Sistemas Operativos no tienen los medios suficientes para suspender un proceso, eliminarlo del sistema y reanudarlo más tarde. - Actualmente, la recuperación se suele realizar eliminando un proceso y quitándole sus recursos. El proceso eliminado se pierde, pero gracias a esto ahora es posible terminar. Algunas veces es necesario, eliminar varios procesos hasta que se hayan liberado los recursos necesarios para que terminen los procesos restantes. - Los procesos pueden eliminarse de acuerdo con algún orden de prioridad, aunque es posible que no existan prioridades entre los procesos bloqueados, de modo que el operador necesita tomar una decisión arbitraria para decidir que procesos se eliminarán.
- Recuperación Manual - Está forma de recuperación consiste en avisarle al administrador o al operador del sistema que se ha presentado un interbloqueo, y será el administrador el que solucione dicho problema de la manera más conveniente posible, de modo que su decisión no afecte demasiado a al usuario del proceso en conflicto, y sobre todo que no afecte a los demás usuarios del sistema


2.13 PRICIPIOS DE INTERBLOQUEO

El interbloqueo se puede definir como el bloqueo permanente de un conjunto de procesos que compiten por los recursos del sistema o bien se comunican unos con otros. A diferencia de otros problemas de la gestión concurrente de procesos, no existe una solución eficiente para el caso general.
Todos los interbloqueos suponen necesidades contradictorias de recursos por parte de dos o más procesos.
Los recursos son de dos tipos:
-         Apropiable
-         No apropiables
Un recurso apropiable es aquel que se puede tomar del proceso que lo posee sin efectos dañinos. La memoria es un ejemplo de recurso apropiable.
Por el contrario, un recurso no apropiable, es aquel que no se puede tomar de su poseedor activo sin provocar un fallo de cálculo. Si un proceso comienza a imprimir una salida, se toma la impresora y se le da a otro proceso, el resultado será una salida incomprensible. Las impresoras no son apropiables.
La secuencia de eventos necesaria para utilizar un recurso es:
-         Solicitar el recurso
-         Utilizar el recurso
-         Liberar el recurso
Si el recurso no está disponible cuando se le solicita, el proceso solicitante debe esperar. En algunos sistemas operativos, el proceso se bloquea de manera automática al fallar una solicitud de un recurso y se despierta cuando dicho recurso está disponible. En otros sistemas la solicitud falla con un código de error y el proceso solicitante debe esperar un poco e intentar de nuevo.
Un proceso cuya solicitud de un recurso ha sido denegada entra por lo general en un ciclo, en el cual solicita el recurso, duerme e intenta de nuevo.
Aunque este proceso no está bloqueado, para todos los efectos esta como bloqueado, puesto que no puede hacer ninguna labor útil. El interbloque se puede definir entonces de la siguiente forma: Un conjunto de procesos se encuentra en estado de interbloqueo cuando cada uno de ellos espera un suceso que solo puede originar otro proceso del mismo conjunto
PREVENCIÓN DEL INTERBLOQUEO

La estrategia básica de la prevención del interbloqueo consiste, a grandes rasgos, en diseñar su sistema de manera que esté excluida, a priori, la posibilidad de interbloqueo.
Los métodos para prevenir el interbloqueo son de dos tipos:
-         Los métodos indirectos que consisten en impedir la aparición de alguna de las tres condiciones necesarias para que se de el interbloqueo.
-         Los métodos directos que consisten en evitar la aparición del circulo vicioso de espera.

Exclusión mutua
Si ningún recurso se puede asignar de forma exclusiva, no se producirá interbloqueo. Sin embargo, existen recursos para los que no es posible negar la condición de exclusión mutua. No obstante, es posible eliminar esta condición en algunos procesos. Por ejemplo, una impresora es un recurso no compatible pues si se permite que dos procesos escriban en la impresora al mismo tiempo, la salida resulta caótica. Pero con el spooling de salida varios procesos pueden generar salida al mismo tiempo. Puesto que el spooler nunca solicita otros recursos, se elimina el bloqueo originado por la impresora.
El inconveniente es que no todos los recursos pueden usarse de esta forma (por ejemplo, la tabla de procesos no se presenta al spooling y, además, la implementación de esta técnica puede introducir nuevos motivos de interbloqueo, ya que el spooling emplea una zona de disco finita)
 No apropiación
La condición de no apropiación puede prevenirse de varias formas. Primero, si a un proceso que retiene ciertos recursos se le deniega una nueva solicitud, dicho proceso deberá liberar sus recursos anteriores y solicitarlos d eneuvo, cuando sea necesario, junto con el recurso adicional. Por otra parte, si un proceso solicita un recurso que actualmente está retenido por otro proceso, el sistema operativo debe expulsar al segundo proceso y exigirle que libere sus recursos. Este último esquema evitará el interbloqueo sólo si No hay dos procesos que posean la misma prioridad.
Esta técnica es práctica sólo cuando se aplica a recursos cuyo estado puede salvarse y restaurarse más tarde de una forma fácil, como es el caso de un procesador.

PREDICCIÓN DEL INTERBLOQUEO

Una forma de resolver el problema del interbloqueo, que se diferencia sutilmente de la prevención, es la predicción del interbloqueo. En la prevención de interbloqueo, se obligaba a las solicitudes de recursos a impedir que sucediera , por lo menos, alguna de las cuatro condiciones de interbloqueo. Esto se hace indirectamente, impidiendo la aparición de una de las tres condiciones necesarias (exclusión mutua, retención y espera, no apropiación) o directamente, impidiendo la aparición de un circulo viciosos de espera. Se llega así a un uso ineficiente de los recursos y una ejecución ineficiente de los procesos. Con predicción del interbloqueo, por otro lado, se pueden alcanzar las tres condiciones necesarias, pero se realizan elecciones acertadas para asegurar que nunca se llega al punto de interbloqueo. La predicción, por lo tanto, permite más concurrencia que la prevención.
Con predicción del interbloqueo, se decide dinámicamente si la petición  actual de asignación de un recurso podría, de concederse, llevar potencialmente a un interbloqueo. La predicción del interbloqueo necesita, por lo tanto, conocer las peticiones futuras de recursos.
Enfoques para la predicción del interbloqueo:
-         No iniciar un proceso si sus demandas pueden llevar a interbloqueo.
-         No conceder una solicitud de incrementar los recursos de un proceso si esta asignación puede llevar a interbloqueo.


Negativa de asignación de recursos
La estrategia de negar la asignación de recursos, denominada algoritmo del banquero, fue propuesta por primera vez por Hijastra, que usó este nombre por la analogía de este problema con el de un banco cuando los clientes quieren obtener dinero prestado. Los clientes sería los procesos y el dinero a prestar, los recursos. Si se enuncia de esta manera, el banco tiene una reserva limitada de dinero para prestar y un conjunto de clientes con líneas de crédito. Un cliente puede elegir pedir dinero a cargo de la línea de crédito en un instante dado y no hay garantía de que el cliente realice ninguna reposición hasta después de sacar la cantidad máxima. El banquero puede rechazar un préstamo a un cliente si hay riesgo de que el banco no tenga fondos suficientes para hacer préstamos futuros que los clientes finalmente repondrán.
Para empezar se definen los conceptos de estado y de estado seguro. Considérese un sistema con un número fijo de procesos. Así pues, el estado estará formado por los dos vectores, Recursos y Disponible, y las dos matrices, Demanda y Asignación, definidas anteriormente. Un estado seguro es un estado en el cual existe al menos una secuencia que no lleva al interbloqueo ( es decir, todos los procesos pueden ejecutarse hasta el final). Un estado inseguro es, naturalmente, un estado que no es seguro.
El algoritmo del banquero usa una tabla de recursos para saber cuántos recursos tiene de todo tipo. También requiere que los procesos informen del máximo de recursos que va a usar de cada tipo. Cuando un proceso pide un recurso, el algoritmo verifica si asignándole ese recurso todavía le quedan otros del mismo tipo para que alguno de los procesos en el sistema todavía se le pueda dar hasta su máximo. Si la respuesta es afirmativa, el sistema se dice que está en 'estado seguro' y se otorga el recurso. Si la respuesta es negativa, se dice que el sistema está en estado inseguro y se hace esperar a ese proceso.
 DETECCIÓN DEL INTERBLOQUEO
  Las estrategias de prevención de interbloqueo son muy conservadoras; resuelven el problema limitando el acceso a recursos e imponiendo restricciones sobre los procesos. En cambio, las estrategias de detección de interbloqueo, no limitan el acceso a recursos ni restringen las acciones del proceso. Con la detección del interbloqueo, se concederán los recursos  que los procesos necesiten siempre que sea posible.  Periódicamente, el S. O.  ejecuta un algoritmo que permite detectar la condición de circulo vicioso de espera.
La detección del interbloqueo es el proceso de determinar si realmente existe un interbloqueo e identificar los procesos  y recursos implicados en él. Una posibilidad detectar un interbloqueo es monitorear cada cierto tiempo el estado de los recursos. Cada vez que se solicita o se devuelve un recurso, se actualiza el estado de los recursos y se hace una verificación para observar si existe algún ciclo.
Este método está basado en suponer que un interbloqueo no se presente y que los recursos del sistema que han sido asignados, se liberarán en el momento que otro proceso lo requiera.
 Algoritmo de detección del interbloqueo
Una comprobación para interbloqueo puede hacerse con igual o menor frecuencia que cada solicitud de recursos, dependiendo de que tan probable es que ocurra un interbloqueo. Comprobar cada solicitud de recursos tiene dos ventajas: Conduce a la detección temprana y el algoritmo es simple, de manera relativa porque se basa en cambios crecientes al estado del sistema. Además, las comprobaciones frecuentes consumen un tiempo considerable de procesador.

Recuperación de Interbloqueo
Cuando se ha detectado que existe un interbloqueo, podemos actuar de varias formas. Una posibilidad es informar al operador que ha ocurrido un interbloqueo y dejar que el operador se ocupe de él manualmente. La otra posibilidad es dejar que el sistema se recupere automáticamente del interbloqueo. Dentro de esta recuperación automática tenemos dos opciones para romper el interbloqueo: Una consiste en abortar uno o más procesos hasta romper la espera circular, y la segunda es apropiar algunos recursos de uno o más de los procesos bloqueados.
La recuperación después de un interbloqueo se complica porque puede no estar claro que el sistema se haya bloqueado. Las mayorías de los Sistemas Operativos no tienen los medios suficientes para suspender un proceso, eliminarlo del sistema y reanudarlo más tarde.
Actualmente, la recuperación se suele realizar eliminando un proceso y quitándole sus recursos. El proceso eliminado se pierde, pero gracias a esto ahora es posible terminar. Algunas veces es necesario, eliminar varios procesos hasta que se hayan liberado los recursos necesarios para que terminen los procesos restantes.
Los procesos pueden eliminarse de acuerdo con algún orden de prioridad, aunque es posible que no existan prioridades entre los procesos bloqueados, de modo que el operador necesita tomar una decisión arbitraria para decidir que procesos se eliminarán.


Recuperación Manual
Está forma de recuperación consiste en avisarle al administrador o al operador del sistema que se ha presentado un interbloqueo, y será el administrador el que solucione dicho problema de la manera más conveniente posible, de modo que su decisión no afecte demasiado a al usuario del proceso en conflicto, y sobre todo que no afecte a los demás usuarios del sistema.

Abortar los Procesos
Para eliminar interbloqueos abortando un proceso, tenemos dos métodos; en ambos, el sistema recupera todos los recursos asignados a los procesos terminados.
1 ) Abortar todos los procesos interbloqueos. Esta es una de las soluciones más comunes, adoptada por Sistemas Operativos. Este método romperá definitivamente el ciclo de interbloqueo pero con un costo muy elevado, ya que estos procesos efectuaron cálculos durante mucho tiempo y habrá que descartar los resultados de estos cálculos parciales, para quizá tener que volver a calcularlos más tarde.
2 ) Abortar un proceso en cada ocasión hasta eliminar el ciclo de interbloqueo. El orden en que se seleccionan los procesos para abortarlos debe basarse en algún criterio de costo mínimo. Después de cada aborto, debe solicitarse de nuevo el algoritmo de detección, para ver si todavía existe el interbloqueo. Este método cae en mucho tiempo de procesamiento adicional.
Quizá no sea fácil abortar un proceso. Si éste se encuentra actualizando un archivo, cortarlo a la mitad de la operación puede ocasionar que el archivo quede en un mal estado.
Si se utiliza  el método de terminación parcial, entonces, dado un conjunto de procesos bloqueados, debemos determinar cuál proceso o procesos debe terminarse para intentar romper el interbloqueo. Se trata sobre todo de una cuestión económica, debemos abortar los procesos que nos representen el menor costo posible. Existen muchos factores que determinan el proceso que se seleccionará, siendo los principales los siguientes:
  1. La prioridad del proceso. Se elimina el proceso de menor prioridad.
  2. Tiempo de procesador usado. Se abortará aquel proceso que haya utilizado menos tiempo el procesador, ya que se pierde menos trabajo y será más fácil recuperarlo más tarde.
  3. Tipos de recursos utilizados. Si los recursos son muy necesarios y escasos será preferible liberarlos cuanto antes.
  4. Cuántos recursos más necesita el proceso. Es conveniente eliminar a aquellos procesos que necesitan un gran número de recursos.
  5. Facilidad de suspensión / reanudación. Se eliminarán aquellos procesos cuyo trabajo perdido sea más fácil de recuperar.

Apropiación de Recursos
Para eliminar interbloqueos utilizando la apropiación de recursos, vamos quitando sucesivamente recursos de los procesos y los asignamos a otros hasta romper el ciclo de interbloqueo.
Si se utiliza la apropiación de recursos para tratar los interbloqueos, hay que considerar tres aspectos:
-         Selección de la víctima
-         Retroceso
-         Bloqueo indefinido

La detección y recuperación es la estrategia que a menudo se utiliza en grandes computadoras, especialmente sistemas por lote en los que la eliminación de un proceso y después su reiniciación suele aceptarse.

2.12 CONCURRENCIA E INTERBLOQUEO (DEADLOCK)

Interbloqueo (dead bck)
 Es un programa de procesos ejecutándose  a un sistema (computador).  Un conjunto de recursos que son utilizados por dichos procesos.
 Se dice  que el conjunto de procesos se encuentra en un estado de  interbloqueo cuando todos los sus procesos se encuentran  esperando un recurso que mantiene  reteniendo otro proceso  de grupo.
Es un proceso esperando un evento que jamás se producirá (lo que produce uno que está esperando también). Dead bck
Concurrencia.
Comprende un gran número de cuestiones de diseño, incluyendo la la comunicación  entre procesos, comparación y comparecía por los recursos. Sincronización de la ejecución de varios procesos y asignación del tiempo de procesador a los procesos y es fundamental para que existan diseños  como multiprogramación, multiprocesos y proceso distribuido.
Los procesos son concurrentes si existen simultáneamente cuando dos o más procesos llegan al mismo tiempo a ejecutarse, se dice que  se  ha procesado una concurrencia de procesos.
Condiciones  para los interbloqueos  de recursos.
Condición de exclusión mutua: cada recurso se asigna en un momento dado a  solo un proceso o estar disponible.
Condición de condencion y espera: los procesos que actualmente  contiene recursos que se les otorgaran antes pueden solicitar nuevos recursos.
Condición no apropiativa: los recursos otorgados previamente  no se pueden quitar a un proceso por la fuerza deben  ser liberadas de manera explícita por el proceso que los  contiene.
Condición de espera circular: deben ser una cadena  circular de dos o más  procesos cada una  de los cuales espera un recurso contenido por el siguiente  miembro de la cadena.
                                      

2.11 PASOS DE MENSAJE

 El pasa de mensaje es una técnica  empleada en programación  concurrente para  aportar sincronización entre procesos  y permitir a la exclusión mutua  de manera similar a como se hace  con los semáforo, monitores, etc.
Su principal característica  es que no precisa  de manera  compartida, por  lo que es muy importante  en la programación  para sistemas distribuidos. Los elementos principales  que intervienen en el paso de mensajes es el proceso que envía, el que recibe  y el mansaje.
 Sistemas embebidos:
 Un sistema embebido o emporrado  es un sistema de computación diseñado para realizar una o algunas pocas funciones dedicadas frecuentemente a un sistema de computación  en tiempo real. Los sistemas embebidos se utilizan para usos muy diferentes a los usos generales  a los que suelen someterse  a las computadoras personales.
Por lo general los sistemas embebidos  la mayoría de los componentes  se encuentran incluidos en la placa base (la tarjeta de video, audio, modem etc.) aunque muchas veces los dispositivos no  lucen como computadoras, ejemplo relojes de taxi, registradoras, controles de acceso. Entre otras múltiples aplicaciones.
 Los componentes del monitor  son:
Inicialización. Contienen código a ser ejecutado cuando el   monitor es creado.
Datos privados.  Contiene  los procedimientos    privados  que solo pueden ser usados desde adentro del monitor  y no son visibles desde afuera.
Procedimiento del monitor.  Son los procedimientos que pueden a ser llamado  desde  fuera del monitor.
Caja de entrada.  Contiene a los hilos  que han llamado algún procedimiento  del monitor pero no han podido  adquirir permiso  para ejecutarlos  aun.
                                                   
                                                          Ventajas de monitores
1)      El control de los recursos  esta centralizado en el  monitor,  lo que hace más fácil  su mantenimiento. A diferencia de los  semáforos  que se  usa  código distribuidos en varias partes del programa.
2)      Prevé una mayor protección a las variables de control.

Desventajas de los monitores
1)      Los monitores tiene exclusividad de uso, es decir  la concurrencia está limitada  si muchos procesos  hacen uso del mis monitor.
2)      El uso de los monitores  es bastante costoso. Por qué se pierde eficiencia y  por tanto ay bloqueo de los procesos.

2.10 Monitores

Son objetos destinados a ser usados  sin peligro por más de  un hilo  de  ejecución.  La característica principalmente los define  en que sus métodos son  ejecutados  con exclusión mutua lo que  significa, que encada  momento  en el tiempo, un hilo como máximo puede estar  ejecutado  cualquiera de sus  métodos.  Esta exclusión mutua simplifica el racionamiento  de implementar monitores en lugar de código  a ser  ejecutado  en  paralelo.
El estado   y el estudió de los semáforos se puede ver en las llamadas a las funciones necesarias para utilizarlos que dan ser repetidas en el código del programa, haciendo fácil corregir errores y asegurar el buen funcionamiento de los algoritmos. Para evitar estos inconvenientes  desarrollando los monitores.
Monitores con señales
       Un monitor es un módulo de software que consta de uno o más procedimientos, una secuencia de inicialización y unos datos locales. Las características básicas de un monitor son las siguientes:
1.       Las variables de datos locales están sólo accesibles para los procedimientos del monitor y no para procedimientos externos.
2.       Un proceso entra en el monitor invocando a uno de sus procedimientos.
3.       Sólo 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.
       Solamente una llamada a un módulo monitor puede ser activada por vez. Esto protege a los datos dentro del monitor de accesos simultáneos de múltiples usuarios. Los usuarios que intentan acceder al monitor mientras este está ocupado son bloqueados en una cola de entrada al monitor.
       CWAIT(c): Suspende la ejecución del proceso llamado bajo la condición c. El monitor está ahora disponible para ser usado por otro proceso.
       CSIGNAL(c): Reanuda la ejecución de algún proceso suspendido después de un CWAIT() bajo la misma condición. Si hay varios procesos, elige uno de ellos; si no hay ninguno, no hace nada.

2.9. SEMÁFOROS

                     Funcionamiento de los semáforos

       Dos o más procesos pueden cooperar por medio de simples señales, de forma que se pueda obligar a detenerse a un proceso en una posición determinada hasta que reciba una señal específica. Cualquier requisito complicado de coordinación puede satisfacerse por medio de la estructura de señales adecuada. Para la señalización, se usan variables especiales llamadas semáforos. Para transmitir una señal por el semáforo, los procesos ejecutan la primitiva signal(s). Para recibir una señal del semáforo, los procesos ejecutan la primitiva wait(s); si la señal correspondiente aún no se ha transmitido, el proceso es suspendido hasta que tenga lugar la transmisión. Para lograr el efecto deseado, se pueden contemplar los semáforos como variables que tienen un valor entero sobre el que se definen las tres operaciones siguientes:  
            
1.       Un semáforo debe inicializarse con un valor no negativo.
2.       La operación wait decrementa el valor del semáforo. Si el valor del semáforo se hace negativo, el proceso que ejecuta el wait se bloquea.
3.       La operación signal incrementa el valor del semáforo. Si el valor no es positivo, se desbloquea a un proceso bloqueado por una posición wait.Las primitivas wait y signal se suponen atómicas, es decir, no pueden ser interrumpidas y cada rutina puede considerarse como un paso indivisible. Una versión más limitada es el semáforo binario, que sólo puede tomar los valores 0 y 1.

 En principio los semáforos binarios son más sencillos de implementar y tienen la misma potencia de expresión que los semáforos generales. Tanto en los semáforos como en los semáforos binarios se emplea una cola para mantener los procesos esperando en el semáforo. La política más equitativa mediante la cual se quitan los procesos de dicha cola es la FIFO. La única exigencia estricta es que un proceso no debe quedar retenido en la cola de un semáforo indefinidamente porque otros procesos tengan preferencia.
       Generalmente operadores como WAIT y SIGNAL operan en los semáforos de la siguiente manera. Cuando un proceso ejecuta un operador WAIT que tiene un valor de semáforo en 0, ese proceso se bloquea; si el valor es mayor que cero, el valor del semáforo es disminuido en 1 y el proceso continua. Cuando un proceso ejecuta un operador SIGNAL y hay procesos bloqueados (WAITING), uno de estos procesos es activado (puesto en la cola de listos). Si no hay procesos esperando el valor del semáforo se incrementa en 1. Se asume que procesos bloqueados por semáforos pierden el procesador y entran en una cola de espera (WAITING QUEUE) en vez de producir BUSY WAITING. También se asume que la cola de espera es FIFO.

2.8. EXCLUSIÓN MUTUA: SOLUCIONES PORN HADRWARE Y SOFTWARE.

ALGORITMOS DE SINCRONIZACIÓN CON ESPERA ACTIVA (BUSY WAITING)
Solución simple
       Se utiliza una variable global que indica el estado de la región crítica, la cual es consultada cuando se requiere entrar. Esta solución no funciona si se produce una interrupción inmediatamente antes de que la variable antes mencionada se active. (Similar al Segundo Intento de Dekker)

Algoritmo de Dekker
Primer intento
       Utilizaremos para su descripción el “protocolo del iglú”. Un proceso (P0 o P1) que desee ejecutar su sección crítica entra primero en el iglú y examina la pizarra. Si su número está escrito en ella, el proceso puede abandonar el iglú y continuar con su sección crítica. En caso contrario, abandona el iglú y se ve obligado a esperar, ingresando de vez en cuando para mirar la pizarra hasta que se le permita entrar a su sección crítica. Un proceso frustrado no puede hacer nada productivo hasta que obtiene permiso para entrar a su sección crítica (por ello, el nombre de espera activa), debiendo persistir y comprobar periódicamente el iglú, consumiendo tiempo del procesador mientras espera su oportunidad.
            Después de que un proceso haya obtenido acceso a su sección crítica y tras terminar con ella, debe volver al iglú y escribir el número del otro proceso en la pizarra.
Esta secuencia podría prolongarse indefinidamente y ningún proceso podría entrar en su sección crítica. Estrictamente hablando, esto no es un interbloqueo, porque cualquier cambio en la velocidad relativa de los dos procesos rompería este ciclo y permitiría a uno entrar en la sección crítica. Aunque no es probable que esta situación se mantenga por mucho tiempo, es una situación posible. Así entonces, se rechaza el cuarto intento.
Una solución correcta
            Hay que poder observar el estado de ambos procesos, que viene dado por la variable señal. Y de algún modo, se hace necesario imponer algún orden en la actividad de los dos procesos para evitar el problema de “cortesía mutua” que se observó en el cuarto intento. La variable turno del primer intento puede usarse en esta labor; en este caso, la variable indica qué proceso tiene prioridad para exigir la entrada a la sección crítica. Ahora hay un iglú “árbitro” con una pizarra llamada “turno”. Cuando P0 quiere entrar en su sección crítica, pone su señal a cierto. A continuación, va y mira la señal de P1. Si ésta está puesta a falso, P0 puede entrar inmediatamente en su sección crítica. En otro caso, P0 va a consultar al árbitro. Si encuentra turno = 0, sabe que es momento de insistir y comprueba periódicamente el iglú de P1. Este otro se percatará en algún momento de que es momento de ceder y escribirá “falso” en su pizarra, permitiendo continuar a P0. Después de que P0 haya ejecutado su sección crítica, pone su señal a “falso” para liberar la sección crítica y pone turno = 1 para traspasar el derecho de insistir a P1.
          PROCESO 0     PROCESO 1    
       begin                                          begin
            repeat                                         repeat
                 señal_a = True;                           señal_b = True;
                 while (señal_b) do                        while (señal_a) do
                     if (turno) then                               if (!turno) then
                          begin                                          begin
                          señal_a = Falso;                         señal_b = Falso;
                          while (turno) do (nada);                         while (!turno) do (nada);
                          señal_a = True;                           señal_b = True;
                          end;                                           end; 
                 < sección crítica >;                      < sección crítica >
                 turno = 1;                                    turno = 0;
                 señal_a = Falso;                          señal_b = Falso;
                 < resto >;                                    < resto >;
            forever;                                            forever;
       end;                                            end;

Algoritmo de Peterson
       El algoritmo de Dekker resuelve el problema de la exclusión mutua, pero con un programa complejo. Entonces, Peterson desarrolló una solución más simple: la variable global señal indica la posición de cada proceso con respecto a la exclusión mutua y la variable global turno resuelve los conflictos de simultaneidad. Este algoritmo puede generalizarse para el caso de n procesos.
PROCESO 0                                               PROCESO 1          
begin                                                           begin
       repeat                                                  repeat
            señal_a = True;                                      señal_b = True;
            turno = 1;                                              turno = 0;
            while (señal_b and turno) do (nada);   while (señal_a and !turno) do (nada);
            < sección crítica >;                      < sección crítica >;
            señal_a = Falso;                          señal_b = Falso;
            < resto >;                                    < resto >;
       forever;                                                 forever;
end;                                                       end;