 Mensaje: #1
Aporto VoF de finales resueltos, solo de Sincronización y Deadlock, algunos resueltos por mi y otros los encontré resueltos, la idea es debatir cuales estan mal.
Una condición de carrera (Race Condition) ocurre cuando, independientemente del orden de ejecución de dos o más procesos, el recurso compartido queda siempre en un estado inconsistente.
Falso, la condición de carrera es una situación en la cual múltiples hilos o procesos leen y escriben un dato compartido y el resultado final depende del orden de la ejecución de instrucciones en los múltiples procesos.
La diferencia fundamental entre competencia y cooperación de procesos es que en la primera la sincronización es realizada solamente por los procesos, mientras que en la segunda necesariamente debe participar el sistema operativo.
Falso, Es al revés. En la competencia, la sincronización es realizada por el sistema operativo, mientras que en la cooperación, es realizada por los procesos.
Con el paralelismo independiente, no existe sincronización explícita entre los procesos.
Verdadero, cada uno representa una separación, una aplicación independiente.
Una falla en el mecanismo de sincronización de procesos concurrentes puede generar el fenómeno de inversión de prioridades.
Verdadero ya que si un proceso de menor prioridad lockea un recurso necesario por ambos procesos el proceso de mayor prioridad no podrá continuar hasta que el otro haya finalizado.
Sistemas que utilizan soluciones hardware para garantizar la mutua exclusión pueden presentar el problema de inversión de prioridades.
Verdadero, las soluciones por hardware hacen que los procesos se amontonen cuando no pueden entrar a la sección critica, cuando un proceso puede entrar a esta la selección es arbitraria.
La instrucción Test and Set, no sujeta a interrupción, como una solución hardware al problema de la exclusión mutua se define como sigue: La instrucción comprueba el valor de su argumento i. Si el valor es 1, entonces la instrucción reemplaza el valor por 0 y devuelve cierto. En caso contrario, el valor no se cambia y devuelve falso.
Falso. Si el valor es 0, entonces la instrucción reemplaza el valor por 1 y devuelve cierto. En caso contrario, el valor no se cambia y devuelve falso. Stallings Pág. 213
La gran desventaja que tienen las instrucciones TSL (test and set instructions) es que no pueden trabajar en sistemas con múltiples procesadores, lo que si pueden ser realizado por los semáforos.
Falso, los TSL son ideales para múltiples procesadores aunque no previene que hay deadlock o starvation.
El algoritmo de Peterson es una estrategia para la sincronización de procesos.
Verdadero. Si consideramos que la mutua exclusión es un método de sincronización de procesos que permite no compartir una región crítica podemos decir que el el Algoritmo de Peterson es una estrategia para la sincronización de procesos ya que es una estrategia para la mutua exclusión. Sin embargo, si se considera que la mutua exclusión es un concepto independiente de la sincronización, es decir que la mutua exclusión no es un metodo de sincronización de procesos, la respuesta sería FALSA.
Si sincronizo KLTS o procesos mediante semáforos y por lo menos tantas pruebas de escritorio como cantidad de semáforos se han colocado, funcionan correctamente, se puede inferir que la sincronización está bien realizada y funcionará correctamente.
Falso porque depende del orden en que se ejecuten los procesos.
La variable interna que guarda el valor del semáforo sólo puede ser modificada utilizando las funciones wait y signal (o sus equivalentes p y v, down y up, etc).
Falso, también es modificada al inicializarse
La sincronización de procesos mediante semáforos permite liberar al procesador más rápidamente cuando un proceso no consigue un recurso.
Verdadero porque cuando sea hace un wait y no se consigue el recurso se bloquea el proceso permitiendo atender a otro proceso.
El pasaje de mensajes es útil para la comunicación entre procesos pero necesita de los semáforos para realizar la mutua exclusión.
Falso. El pasaje de mensajes es uno de los modelos de comunicación entre procesos más comunes (junto con el de memoria compartida), es suficiente para la mutua exclusión; y no necesita el uso de semáforos. El paso de mensajes puede ser directo o indirecto a través de mailboxes (buzones).
Los semáforos son herramientas que se emplean únicamente para resolver el problema de la exclusión mutua y para ello, basta con implementar un semáforo MUTEX.
Falso, también existen semáforos contadores para cuando el recurso tiene varias instancias.
En los semáforos sin espera activa se utiliza una cola asociada para los procesos que esperan. Esto puede provocar en algunos procesos starvation, porque el algoritmo para dar de baja en la cola no necesariamente tiene que ser de tipo FIFO.
Falso. Ningún semáforo presenta espera activa, y todos los semáforos tiene una cola asociada para los procesos que esperan. Un semáforo que no especifica el orden en que los procesos son extraídos de la cola es un semáforo débil. Los semáforos que utilizan FIFO para extraer procesos de la cola de bloqueados se conocen como semáforos fuertes.[Stallings, 5ª ed. Esp., Pg. 218].
Un semáforo es una función protegida por el sistema operativo que permite sincronizar el acceso a un recurso dentro de un ambiente multiprogramado.
Falso, un semáforo no es una función.
Si se tienen dos procesos concurrentes que utilizan algún mecanismo de sincronización, entonces no pueden estar simultáneamente dentro de una región crítica.
Falso, podrían estar dentro de una región crítica si se sincronizó con semáforos contadores.
Cuando un proceso quiere ingresar a una variable compartida, debe ejecutar un semáforo para preservar la mutua exclusión.
Falso. Los semáforos no se ejecutan, lo que se ejecutan son instrucciones P/down/wait() o V/up/signal() sobre los semáforos.
Los pipes en Unix son archivos cuyo funcionamiento puede aprovecharse para la sincronización de procesos.
Verdadera, los pipes tienen file descriptors y se puede trabajar con las funciones de archivos y además permiten sincronización a través del modelo productor consumidor.
Los monitores son una colección de procedimientos, variables y estructuras de datos que se agrupan en un cierto tipo de módulo particular y garantizan la exclusión mutua por si solos.
Verdadero, por definición.
Si un proceso, ejecutando código de un procedure de un monitor, ejecuta una operación WAIT sobre una variable condición, el proceso espera “dentro” del monitor en una cola de procesos bloqueados asociada a dicha variable
Falso. Si el proceso queda bloqueado pero como “ejecutando” dentro de un monitor, ningún otro proceso podrá acceder a la variable condición (sobre la cual el proceso original hizo el WAIT) para hacer el SIGNAL correspondiente que despierte al proceso dormido. Recordar que cualquier acceso a una variable condición definida en un monitor DEBE hacerse ejecutando código del mismo, y que solamente un único proceso puede figurar como “ejecutando” código del monitor en un momento dado (por la exclusión mutua que estas construcciones proveen); cualquier otro proceso que haya invocado al monitor se bloquea en espera de que quede disponible.
Los monitores son un mecanismo más fácil de usar que los semáforos, aunque tienen la desventaja de que sólo sirven para garantizar la mutua exclusión.
Verdadero, sólo un proceso se puede estar ejecutando dentro del monitor al mismo tiempo, cualquier otro proceso que haya invocado al monitor se bloquea, en espera que el monitor quede disponible.
Si dentro de un monitor se tienen varios procesos suspendidos en una condición “X” y un proceso ejecuta un signal() en esa condición, el orden de ejecución del próximo proceso suspendido es LIFO.
Falso. Es FIFO. [Silberchatz-Galvin, 7ª ed. Esp., Pg. 191].
En monitores con notify y broadcast, si el proceso que ejecuta un signal no termina su ejecución dentro del monitor, entonces son necesarios dos cambios de procesos (processes switch).
Verdadero, ocurre cuando cambia el modo de usuario a kernel y de kernel a usuario.
A pesar de implementar monitores como mecanismo de sincronización, en Java es posible implementar una solución del problema de los filósofos.
Verdadero, con los monitores también se puede sincronizar los procesos. Los monitores garantizan la sincronización necesaria para la resolución del problema de los filósofos.
Cuando un proceso que se encuentra dentro de un monitor realiza una operación WAIT sobre una variable de condición, el proceso espera fuera del monitor en una cola de procesos bloqueados asociada a dicha variable de condición.
Falso, espera dentro del monitor por esa condición. En monitores la operación WAIT no existe, sino que la primitiva se llama CWAIT.
El término espera activa (busy waiting) se refiere a que un proceso no puede hacer nada o ejecutar hasta obtener permiso para entrar en su región crítica.
Falso. Busy Waiting (espera activa) se refiere a que el proceso entra en un ciclo (while, for) preguntando por una condición y hasta que no se cumpla esa condición el proceso no sale del ciclo. [Stallings, 5ª ed. Esp., Pg. 213].
El Bussy Waiting se produce siempre que un proceso ejecuta un ciclo y tiene como desventaja que empeora la performance del sistema.
Falso, un proceso con espera activa empeora la performance del sistema porque usa tiempo de procesador para esperar un recurso.
La técnica para evitar la Inanición (Starvation) es matar al proceso que no consigue el recurso.
Falso. Un proceso que sufre de inanición precisamente necesita que se le asigne el recurso que espera, si eliminamos ese proceso se termina la inanición de éste a un costo muy alto, ya que el proceso nunca habrá concluido su trabajo satisfactoriamente (muerte por inanición). (“seria como curar una enfermedad matando al paciente”). La inanición se puede evitar mediante una correcta sincronización de procesos que compiten por recursos críticos. Ahora cuando se produce un deadlock, eliminar procesos que intervienen en él si es una alternativa (pero no es una técnica para evitarlo, sino para recuperarse de un deadlock). Otra alternativa de recuperación es la apropiación de recursos, desalojar en forma sucesiva recursos de proceso y asignarlos a otros hasta que se interrumpe el deadlock.[Stallings, 5ª ed. Esp., Pgs. 203, 209].
Únicamente se produce starvation por el uso inadecuado de herramientas de sincronización.
Falso, también puede ocurrir por una mala planificación. Puede producirse starvation en la utilización de herramientas de planificación. Por ejemplo en la utilización de SPN (Shortest Process Next) en la planificación de procesos, puede, en algunos casos, producirse starvation con los procesos largos.
El problema de los lectores/escritores puede tratarse como una situación particular del productor/consumidor, pero la solución sería extremadamente ineficiente.
Falso, un productor no es solo un escritor y un consumidor no es solo un lector, el productor y el consumidor utilizan punteros para ver donde escribir y ver si el buffer está lleno o vacío, mientras los lectores consumidores no.
Que ciertas instrucciones se ejecuten de forma atómica significa que no se pueden ejecutar concurrentemente.
Falso, significa que es una operación que no es interrumpida hasta que finaliza su procesamiento, se podrían ejecutar concurrentemente en en distintos procesadores.
La Mutua Exclusión de dos secciones críticas asegura que éstas se ejecuten atómicamente en forma concurrente.
Falso, una operación atómica significa que no es interrumpida hasta que finaliza su procesamiento.
Es deseable que todos los procesos (o al menos de misma prioridad) tengan la misma probabilidad de adquirir recursos.
Verdadero, si un proceso tuviese una probabilidad muy baja de adquirir un recurso y a su vez este está reteniendo muchos otros recursos que son requeridos por otros procesos es poco deseable porque tardaría mucho tiempo para liberar sus recursos.
Una de las ventajas que posee el mecanismo de inhabilitar y habilitar las interrupciones para lograr mutua exclusión es que nunca podrá generarse deadlock ni starvation entre procesos.
Falso, en una arquitectura multiprocesador, el mecanismo de inhabilitar y habilitar las interrupciones no garantiza exclusión mutua pero con un solo procesador sí.
En un sistema multiprocesador, deshabilitar las interrupciones de un procesador es suficiente para solucionar el problema de la sección crítica.
Falso, ya que si se deshabilitan las interrupciones, otro procesador puede estar ejecutando en la sección critica que se intenta entrar.
La inhabilitación de interrupciones como mecanismo para garantizar la exclusión mutua a una sección crítica tiene sentido en Sistemas Operativos con multiprocesamiento.
Falso, ya que si se deshabilitan las interrupciones, otro procesador puede estar ejecutando en la sección critica que se intenta entrar.
En un sistema multiprocesador, deshabilitar las interrupciones no garantiza la mutua exclusión.
Verdadero. ya que si se deshabilitan las interrupciones de un procesador, otro procesador puede estar ejecutando en la sección critica que se intenta entrar.
Los conflictos involucrados en un Deadlock se deben a 2 o más procesos y no a la necesidad de recursos que necesitan esos procesos
Falso, se debe a los recursos que necesitan los procesos . [Stallings, 5ª ed. Esp., Pg. 266].
En un Sistema que contiene una única instancia de cada recurso, la espera circular es una condición necesaria y suficiente para la existencia de Deadlock.
Falso, las 4 condiciones de Coffman deben cumplirse para que exista deadlock.
La cuarta condición de Coffman (Espera Circular) es necesaria y suficiente para la existencia de deadlock si se tiene un sistema con recursos de una sola instancia.
Verdadero, porque todos los procesos en ese conjunto están esperando por un recurso retenido por otro proceso en el conjunto.
Una de las formas de prevención del deadlock es eliminar la condición de mutua exclusión, sobre los recursos.
Verdadero porque al compartir los recursos se dejaría de cumplir una de las 4 condiciones necesarias para la existencia de deadlock.
En el análisis de un grafo se asignación de recursos si los recursos no son compartibles y hay un ciclo, entonces hay un deadlock.
Falso, se tienen que cumplir las otras 2 condiciones necesarias: "sin desalojo" y "retencion y espera".
Si en un conjunto de procesos existe una espera circular es probable que existe o se pueda producir un deadlock.
Verdadero, es condición necesaria pero no suficiente.
Si existe una función F: R --> N que asocia a cada recurso un número natural y un proceso que posee un recurso Ri puede solicitar otro recurso Rj si y sólo si F(Ri) < F(Rj), entonces no se producirá deadlock.
Verdadero, Mecanismo de prevencion que atenta con la espera circular.
Una forma de detectar deadlock, es detectar uno o más procesos con pedidos insatisfechos de recursos.
Falso, Detectar sólo que uno o más procesos tienen pedidos insatisfechos no es detectar deadlock. Para detectar deadlock se deberá analizar si los pedidos de procesos insatisfechos pueden satisfacerse con los recursos disponibles.
Un Livelock es más fácil de detectar que un Deadlock.
Falso porque en el livelock los procesos siguen ejecutándose.
La forma más sencilla de prevenir un deadlock es lograr que se elimine la condición de retención y espera en donde el proceso antes de iniciar la ejecución pide todos los recursos que va a necesitar durante todo el tiempo que este ejecutando.
Verdadero, porque si ya tiene todos los recursos asignados va a poder terminar sin tener que esperar por ningún recurso retenido por otro proceso, sin embargo en ciertos casos sería casi imposible estimar de antemano todos los recursos que va a necesitar.
Una técnica para evitar (avoidance) que se produzcan deadlocks es matar uno de los procesos que intervienen en el deadlook.
Falso, matar un proceso es una solución a un deadlock que ya se había producido, no es una técnica para evitarlo.
El algoritmo del Banquero es un planificador a corto plazo, puesto que decide si otorga un recurso en el mismo momento en que este es solicitado.
Falso. El Algoritmo del banquero, en es una forma de evitar el interbloqueo, decide si le asigna recursos a los proceso que los solicitan para mantener al sistema en un estado seguro. Un planificador es un componente funcional del SO que reparte el tiempo disponible de un microprocesador entre todos los procesos que están disponibles para su ejecución.
Usando el algoritmo del banquero se puede prevenir la ocurrencia de deadlock independientemente de que se produzcan o no las cuatro condiciones necesarias para la existencia del mismo.
Falso, el algoritmo del banquero evita el deadlock y un deadlock solo se puede dar si se produjeron las cuatro condiciones necesarias.
Un estado seguro es aquel estado en el que por lo menos un proceso se puede ejecutar en su totalidad.
Falso, Un estado seguro es uno en el cual existe una forma de asignar los recursos de manera que todos los procesos puedan ejecutar en su totalidad. (STL. 176) -> "Un estado seguro es uno en el cual hay al menos una secuencia que no resulta en deadlock".
Si el estado de un sistema es un estado seguro, entonces no puede haber espera circular.
Falso, El estado de un sistema es seguro si hay una secuencia de ejecución que permita terminar todos los procesos, independientemente si hay una espera circular o no, entonces en un estado seguro se puede dar un espera circular momentáneamente siempre que no se den las tres condiciones restantes (coffman). Una espera circular por sí sola no es condición suficiente.
Si después de correr el algoritmo de detección de deadlock observamos que no hay ningún tipo de interbloqueo podemos asegurar que el sistema está en estado seguro.
Verdadero porque se puede asignar los recursos a los procesos sin que se produzca deadlock.
Mediante la aproximación de instrucciones de máquina para la sincronización de procesos no es posible el Deadlock.
Falso, la ocurrencia de deadlock es independiente de la aproximación de instrucciones a lenguaje máquina.
Si en un SO no existe ninguna cola de bloqueados, entonces está libre de deadlocks.
Falso. Todos los modelos de transiciones de estados de procesos existentes incluyen el estado bloqueado, por lo tanto no puede haber un SO que no contenga ninguna cola de bloqueados.
Desde el punto de vista de la evitación del deadlock, si un sistema está en estado seguro, cualquier solicitud de recursos que efectúe un proceso puede satisfacerse y dejar nuevamente al sistema en estado seguro.
Falso, puede ser que no pueda satisfacerla y por lo tanto no le asigna los recursos.
En sistemas de tiempo real, la mejor implementación para gestionar los inconvenientes de deadlock es el algoritmo del avestruz, debido al bajo costo que acarrea su solución.
Falso, el algoritmo de avestruz no es una solución, es justamente no hacer nada para evitar problema del deadlock.
Solo puede haber Interbloqueos entre threads del mismo proceso.
Falso puede haber deadlock entre threads de distinos procesos que necesiten un mismo recurso.
La evasión de interbloqueos requiere que se proporcione de antemano al sistema operativo información adicional sobre qué recursos solicitará y utilizará un proceso durante su tiempo de vida.
Verdadero porque se necesita determinar una secuencia de ejecución de los procesos para que no termine en deadlock.
|
![[-]](images/collapse.gif)
Alejandro recibio 14 Gracias por este post
![[Imagen: 200px-Monitor_%28synchronization%29-Mesa.png]](https://upload.wikimedia.org/wikipedia/commons/thumb/1/15/Monitor_%28synchronization%29-Mesa.png/200px-Monitor_%28synchronization%29-Mesa.png)
