El algoritmo de espera ocupada de Peterson
El algoritmo de Peterson no es un método de exclusión mutua basado en espera ocupada
Es una variación del algoritmo de Hyman para dos procesos
Es una simplificación del algoritmo de Dekker
Es una variación del algoritmo de Dekker para n procesos
Desde el punto de vista de un Sistema Operativo un proceso es:
Entidad lógica a la que la CPU podrá planificar y asignar recursos
Entidad lógica que se almacena en un dispositivo de almacenamiento
Entidad lógica que podrá ser cargada en memoria para su planificación
Ninguna de las respuestas es correcta
La ejecución concurrente de varios procesos implica:
Una arquitectura del Sistema Operativo que la permita
Que existan múltiples programas dentro del sistema
Un Sistema Operativo monoprogramado
La necesidad de múltiples unidades de procesamiento
Para un correcto funcionamiento de los procesos concurrentes se debe asegurar:
La exclusión mutua y la sincronización
La exclusion mutua, la sincronización y evitar el interbloqueo
Sólo la exclusión mutua
La relación existente entre procesos e hilos es:
Los recursos podrán ser asociados tanto a los procesos como a los hilos
Los hilos están asociados al proceso que los crea
Los procesos son estructuras "ligeras" mientras que los hilos son estructuras "pesadas"
El Sistema Operativo debe manejar la misma información que para el mantenimiento de hilos
La posibilidad que nos permite un sistema multihilo es:
No ofrece ninguna ventaja sobre un sistema multiproceso
Permite una mejor paralelización de un problema sin necesidad de crear nuevos procesos
Son un elemento presente en todos los Sistemas Operativos
Para poder seguir la ejecución de un hilo será necesario almacenar:
La información de contexto, pila y recursos asignados
Al menos la información de contexto y pila
Una cantidad de información similar a la necesaria para gestionar un proceso
La exclusión mutua entre diferentes procesos garantiza:
Sólo es necesaria en Sistemas Distribuidos
El acceso seguro a todos los recursos de un proceso
Que sólo un proceso puede estar dentro de la sección crítica
No es necesario garantizar la exclusión mutua entre procesos
El algoritmo de Dekker:
Sufre de inanición para el problema de la exclusión mutua
Soluciona mediante espera ocupada el problema de la exclusión mutua
Es un algoritmo incorrecto para la solución de la exclusión mutua
Soluciona el problema de sincronización entre procesos
El algoritmo de Peterson frente al de Dekker:
Es más eficiente que el algoritmo de Dekker
No tiene el problema de espera ocupada que sí tiene el de Dekker
Tiene una mejor solución para el problema de sincronización entre procesos
¿Cuándo hablamos que dos o más procesos son concurrentes?
Es suficiente si las instrucciones de los procesos se intercalan en la ejecución
Cuando tenemos al menos tantas unidades de procesamiento como procesos
Sólo en el caso de ejecución paralela
Cuando se ejecutan en ordenadores diferentes
¿Qué son las condiciones de Bernsein?
Ayudan a la sincronización de los procesos
Sirven para determinar las secciones críticas de los procesos
Determinan si un conjunto de instrucciones pueden ejecutarse concurrentemente
Indican si dos o más procesos pueden ejecutarse concurrentemente
En los programas concurrentes:
Se pueden producir resultados diferentes para el mismo conjunto de datos de entrada
El tiempo empleado para terminar la ejecución siempre es la misma
Podemos determinar de forma clara el orden de ejecución de las diferentes instrucciones que lo componen
Para que un programa concurrente sea correcto, deben cumplirse las siguientes propiedad
Seguridad e inanición
Interbloqueo e inanición
Exclusión mutua y viveza
Viveza y seguridad
La exclusión mutua mediante inhibición de interrupciones:
Únicamente garantiza la exclusión mutua en operaciones de E/S
No puede utilizarse en sistemas multiprocesador
Mejora el rendimiento de las aplicaciones
Garantiza la ausencia de inanición
Presenta situaciones en las que puede no garantizar las propiedades de viveza
Es válido para "n" procesos con ligeras modificaciones
Está orientado a entornos centralizados
Está orientado a entornos distribuidos
En términos de eficiencia:
Los monitores son más eficientes que los semáforos
Los algoritmos de espera ocupada son más eficientes que los semáforos
A priori, no puede determinarse qué técnica de sincronización es la más eficiente
La eficiencia de los semáforos depende exclusivamente de la CPU
¿Cuál de las siguientes afirmaciones es cierta?
El paralelismo y la concurrencia son conceptos que no guardan relación alguna
El paralelismo es un tipo de concurrencia
El paralelismo puede desarrollarse en sistemas monoprocesador
La concurrencia es un tipo de paralelismo
La asignación de procesadores físicos a hilos se realiza:
Indirectamente, asignando los procesadores lógicos a una CPU
Directamente, asignando la CPU al proceso del que forma parte un único hilo
Directamente, por parte del planificador del Sistema Operativo
Se hace a dos niveles, un primer nivel para asignar los hilos de usuario a los procesadores lógicos, segundo nivel para asignar los procesadores lógicos al procesador o procesadores físicos
Un interbloqueo (deadlock) se produce:
cuando existe un grupo de procesos que nunca progresan pues no se les otorga tiempo de procesador para avanzar
si el resultado de la secuencia depende de la llegada relativa a algún punto crítico en la secuencia
cuando todos los procesos están esperando que ocurra un evento que nunca se producirá
ninguna de las otras respuestas es cierta
La siguiente solución al problema de los filósofos
No resuelve el problema en ninguna circunstancia
Puede generar interbloqueo entre los procesos
Puede generar inanición en uno de los filósofos
Resuelve el problema cumpliendo todas las propiedas
Dada la siguiente configuraciónn de procesos, determinar la respuesta correcta
A se ejecutará antes de F
B se ejecutará siempre después de C
D se ejecutará después de E y A
D se ejecutará siempre después de B y C
El problema del interbloqueo:
No es un problema que se da en la programación concurrente
Se resuelve mediante el uso de monitores
Se resuelve mediante el uso de semáforos
Las variables de condición en un monitor:
Son necesarias para poder mantener la sincronización de los procesos dentro del monitor
Son como los semáforos dentro del
Controlan diferentes condiciones dentro del monitor
Garantizan la exclusión mutua de las funciones del monitor
La característica principal de un monitor es:
Todas las funciones se ejecutan en exclusión mutua
Sólo hay un proceso en el monitor en cada momento
Solucionan el problema de la sincronización entre procesos concurrentes
Los monitores en relación a los semáforos:
Son herramientas de más alto nivel de programación con una estructura que ayuda a la corrección del programa
Son herramientas de más bajo nivel de programación
No ayudan más que los semáforos
La sentencia "resume" de un monitor:
Sólo se aplica a una variable de condición del monitor si hay procesos bloqueados en la misma.
Librará a un proceso bloqueado en la variable de condición del monitor. Si no hay, no tiene efecto
Permite bloquear a un proceso en el monitor dentro de una variable de condición
Tiene la misma lógica de funcionamiento que la operación "signal" de un semáforo
Los monitores requieren de la utilización y definición de dos tipos de procesos:
Procesos padres y procesos
Proceso monitor y proceso principal
Procesos bloqueados y procesos bloqueantes
Procesos activos y procesos bloqueados
En los monitores los procesos bloqueados:
Se bloquean en las colas de acceso al propio monitor
Se bloquean en las colas asociadas a variables de condición
Podemos tener múltiples procesos bloqueados dentro del monitor
Todas las respuestas son correctas
En la semántica "resume & exit", el proceso desbloqueado por "resume(v)" es:
El primer proceso que estuviera esperando para acceder al monitor
El primer proceso que estuviera bloqueado en la cola de la variable de condición "v"
Se elige aleatoriamente procesos bloqueados en la variable o en el monitor
Los semáforos son:
Herramientas que solucionan el problema de la exclusión mutua
Una estructura de datos con operaciones atómicas para su manejo
Herramientas para solucionar el problema de la concurrencia en Sistemas Distribuidos
La inicialización de la variable de un semáforo:
Sólo puede hacerse una única vez en su ciclo de vida
No se inicializa el el ciclo de vida
Puede inicializarse tantas veces como se quiera
La operación "signal(.)" de un semáforo:
Si hay procesos bloqueados no incrementará el valor de la variable del semáforo
Incrementará siempre el valor de la variable del semáforo
No hará nada con la variable del semáforo
Los semáforos:
Son herramientas de programación para el uso de los programadores en los problemas de concurrencia
Las herramientas de programación garantizan su uso correcto para solucionar el problema de la sincronización entre procesos
Están presentes en todas las herramientas de programación
Las herramientas de programación garantizan su uso correcto para solucionar el problema de la exclusión mutua
En el problema del productor/consumidor resuelto mediante semáforos:
Los procesos productores deben sincronizarse entre sí para garantizar la corrección del problema
Los procesos productores deben sincronizarse con los procesos consumidores para garantizar la corrección del problema
Sólo es necesario garantizar la exclusión mutua al buffer compartido
La operación "wait(s)":
Bloquea el proceso que la ejecuta si "s=1"
Si "s=0" decrementa el valor de "s" y bloquea el proceso
Bloquea al proceso que la ejecuta si "s=0"
Decrementa el valor de "s" y entonces bloquea el proceso si "s=0"
La gestión de los procesos bloqueados en un semáforo:
El Sistema Operativo desbloqueará los procesos en función de la prioridad
Mediante el uso de semáforos, los procesos no pasan a estado
Puede ser FIFO o LIFO
Debe ser siempre FIFO para evitar la inanición
Un semáforo "s" inicializado a 2
El primer proceso que alcance la sentencia "wait" podrá acceder a su sección crítica
Permite que dos procesos entén simultáneamente en su sección
Los semáforos se inicializan siempre a valor 1
Dos procesos podrán ejecutar "wait(s)" sin bloquearse
En los sistemas distribuidos debemos:
Garantizar la correcta sincronización de los procesos
Garantizar la exclusión mutua de las secciones críticas
Garantizar el acceso de los procesos a los recursos locales
En la instrucción de espera selectiva "select", el proceso que la ejecuta se bloquea si:
No se cumple ninguna de las guardas, si las tuviera
La instrucción "select" no genera bloqueo del proceso
No disponga de alternativa "else"
No existe ningún mensaje en los buzones/canales que se manejan
El paso de mensajes entre procesos es necesario para:
Permite intercambiar información entre procesos
El correcto funcionamiento entre procesos dentro de los Sistemas Concurrentes
El correcto funcionamiento entre procesos en un Sistema Distribuido
Soluciona el problema de la exclusión mutua entre procesos en un Sistema Distribuido
En la comunicación directa entre procesos es necesario:
Conocer el destinatario del mensaje
No se requiere ningún tipo de identificación
Conocer el remitente del mensaje
El emisor debe conocer al destinatario y el receptor al remitente
En la comunicación asíncrona entre procesos:
No hay necesidad de buffer en la trans
El buffer sólo se comparte entre emisor y receptor
La primitiva de envío bloqueará al emisor
La primitiva de recepción bloqueará al proceso si no hay datos en el buzón
Ambas primitivas de envío o recepción bloquearán a los procesos implicados
Ninguna primitiva de envío o recepción bloquearán a los procesos implicados
En el problema del productor/consumidor, si la primitiva de envío no bloquea al productor:
El emisor deberá asegurarse que el consumidor esté disponible
No hay solución posible con esa suposición de partida
Deberemos utilizar un buzón de tamaño indefindo
En la comunicación síncrona entre procesos:
El receptor espera siempre al emisor antes de iniciar la tranmisión
Ni emisor ni receptor esperan antes de iniciar la transmisión
El primero que alcanza la primitiva de comunicación deberá esperar hasta que el otro alcance la suya antes de iniciar la transmisión
El emisor espera siempre al receptor antes de iniciar la transmisión
La utilización de un canal:
Permitirá el almacenamiento de información para la comunicación entre procesos
Establecerá el tipo de información que se transmitirán emisor y receptor en una comunicación síncrona
Establecerá el tipo de sincronización necesaria en la comunicación
La utilización de un canal de sincronización:
Permite definir un tipo por defecto en la comunicación síncrona
No existe ese tipo de canales
Es el tipo de canales habituales en las comunicaciones síncronas
Se utilizarán como elemento de sincronización entre procesos en entornos remotos
En el direccionamiento asimétrico del paso de mensajes:
El emisor identifica al receptor, pero el receptor no identifica al emisor
El emisor identifica al receptor y el receptor identifica al emisor
El emisor no identifica al receptor y el receptor no identifica al emisor
El emisor no identifica al receptor pero el receptor identifica al emisor
El paso de mensajes síncrono permite la comunicación:
Muchos a uno
Muchos a muchos
Uno a muchos
Uno a uno
La llamada a un procedimiento remoto:
Es un elemento necesario en la estructura de los Sistemas Distribuidos
Es un tipo de comunicación habitual en Sistemas Distribuidos
Permite la ejecución de un procedimiento presente en un proceso remoto dentro de un Sistema Distribuido
Un proceso que invoca una llamada a un procedimiento remoto:
Desde el punto de vista del programador es transparente como si utilizara una biblioteca perteneciente a su sistema
El programador deberá conocer información relativa a la estructura del proceso remoto
No esperarán a la respuesta por parte del proceso remoto
Sólo implica una degradación de las prestaciones del proceso dentro del sistema
En el proceso de resolución de una llamada a procedimiento remoto:
Los mensajes que han de transmitirse deberá confeccionarlos el programador
Es responsabilidad del sistema la solución a la transmisión de la información
El programador deberá tener presente la codificación de la información en la máquina remota
En la llamada a procedimiento remoto:
Los dos sistemas deberán tener una misma arquitectura
Deberá ser el mismo Sistema Operativo en las máquinas remotas
Se utilizará el mismo lenguaje de programación para codificar los procesos
En las llamadas a procedimiento remoto (RPC), la invocación al resguardo del cliente:
La invoación se realiza siempre de un módulo que se encuentra en otro sistema
Debe garantizar que existe concordancia entre los parámetros
No requiere de conexión entre cliente y servidor
Siempre genera el bloqueo del proceso que realiza la invocación
Cual de las siguientes cuestiones han de resolverse en una llamada a procedimiento remoto
Todas las respuestas son válidas
La respuesta ante fallos de una máquina
La ejecución en espacios de direcciones de memoria diferentes
El paso de parámetros
En el mecanismo de RPC, el resguardo o sustituto del procedimiento invocado se crea
en el lado del servidor
en el lado del cliente
La creación de resguardos o stubs no es una técnica de RPC
En el lado del cliente y en el lado del servidor
En RPC asíncrona:
La resolución a la RPC es bloqueante en servidor
la llamada a procedimiento no es bloqueante en cliente
la llamada a procedimiento es bloqueante en cliente
También es conocida como RPC síncrona extendida
Cual de las siguientes condiciones se requiere para construir el mecanismo de RPC
Los programas deben haberse escrito usando el mismo lenguaje
Mismo tratamiento de RPC en todas las máquinas implicadas
Iguales arquitectura de máquinas
Más de una máquina
Please wait - loading…