Edición de «Práctica Abrazo Mortal (Sistemas Operativos)»

{{Back|Sistemas Operativos}}

===Ejercicio 1===
En principio, no. Es cierto que se puede fabricar un deadlock entre distintos threads de un mismo proceso, pero no es a lo que apunta la pregunta.

===Ejercicio 2*===
En el caso del procesador, no es específicamente un deadlock sino un caso de inanición. En el caso de la memoria y disco sí, sólo que no se trata de tener un recurso 'exclusivo' sino de conseguir espacio (sería tener 2 programas en los que cada uno tiene el 50% del espacio disponible, quieren un poco más, y cada uno espera que el otro libere). Estos problemas se suelen solucionar por medio del desalojo en el caso del procesador y la memoria y con preasignación de espacio en el caso del disco.

===Ejercicio 3===
Dado que hay 4 instancias y 3 procesos, sea cual sea la asignación uno de los procesos va a obtener las 2 instancias que requiere, garantizando su finalización y dejando libres suficientes recursos como para estar seguros de que los otros 2 también van a finalizar.

===Ejercicio 4*===
La Inanición '''es una forma''' de Deadlock. No son lo mismo.

Lo que define la Inanición es la idea de un proceso que '''nunca consigue cierto recurso'''.

Lo que define al Deadlock es la '''espera circular''' donde hay un conjunto de procesos en espera en el cual cada proceso requiere algo que tiene otro proceso del conjunto.

===Ejercicio 5*===
Una dificultad de hacer roll-back es que se deshacen todos los acciones anteriores recorriendo el "log", pero hay operaciones que no se pueden deshacer (por ej: imprimir algo). Ademas es muy costoso mantener la información para poder hacer un roll back.
La ventaja es que si todo sale bien, el sistema sigue funcionando y no se perdió información. 

===Ejercicio 6===

a. Se puede.

b. No se puede.

c. No se puede.

d. Se puede.

e. No se puede.

f. Se puede. 

===Ejercicio 7*===
a.
{| class="wikitable" style="text-align:center"
|
{| border="1"
|+'''MAX'''
!Proceso !!R1 !!R2 !!R3 !!R4
|-
! P1
|0||0||1||2
|-
! P2
|1||7||5||0
|-
! P3
|2||3||5||6
|-
! P4
|0||6||5||2
|-
! P5
|0||6||5||6
|}
|
'''-'''
|
{| border="1"
|+'''ASIGNACIÓN'''
!Proceso !!R1 !!R2 !!R3 !!R4
|-
! P1
|0||0||1||2
|-
! P2
|1||0||0||0
|-
! P3
|1||3||5||4
|-
! P4
|0||6||3||2
|-
! P5
|0||0||1||4
|}
|
'''='''
|
{| border="1"
|+'''NECESIDAD'''
!Proceso !!R1 !!R2 !!R3 !!R4
|-
! P1
|0||0||0||0
|-
! P2
|0||7||5||0
|-
! P3
|1||0||0||2
|-
! P4
|0||0||2||0
|-
! P5
|0||6||4||2
|}
|}

b.
{| class="wikitable" style="text-align:center"
|
{| border="1"
|+ '''AB'''
!PASO
|-
|0
|-
|1
|-
|2
|-
|3
|-
|4
|-
|5
|}
||
{| border="1"
|+'''FINISH'''
!P1 !!P2 !!P3 !!P4 !!P5
|-
|F||F||F||F||F
|-
|T||F||F||F||F
|-
|T||F||T||F||F
|-
|T||T||T||F||F
|-
|T||T||T||T||F
|-
|T||T||T||T||T
|}
||
{| border="1"
|+'''WORK'''
!R1 !!R2 !!R3 !!R4
|-
|1||5||2||0
|-
|1||5||3||2
|-
|2||8||8||6
|-
|3||8||8||6
|-
|3||14||11||8
|-
|3||14||12||12
|}
||
{| border="1"
|+'''ENTONCES'''
!Puedo Seguir?
|-
|P1 cumple <math>\to</math> Work += Asig[1]
|-
|P3 cumple <math>\to</math> Work += Asig[3]
|-
|P2 cumple <math>\to</math> Work += Asig[2]
|-
|P4 cumple <math>\to</math> Work += Asig[4]
|-
|P5 cumple <math>\to</math> Work += Asig[5]
|-
|'''SUCCESS'''
|}
|}

Por lo tanto, el sistema está en estado seguro. La secuencia segura es '''P1 - P3 - P2 - P4 - P5'''

c.
Corriendo el algoritmo del banquero:
*Req[2] <math>\le</math> Nec[2]? (0 4 2 0) <math>\le</math> (0 7 5 0) Sí
*Req[2] <math>\le</math> Disp?  (0 4 2 0) <math>\le</math> (1 5 2 0) Sí

Entonces se cambian:
*Disp -= Req[2] <math>\to</math> Disp = (1 1 0 0)
*Asig[2] += Req[2] <math>\to</math> Asig[2] = (1 4 2 0)
*Nec[2] -= Req[2] <math>\to</math> Nec[2] = (0 3 3 0)

Corriendo el algoritmo de Seguridad:
{| class="wikitable" style="text-align:center"
|
{| border="1"
|+ '''AB'''
!PASO
|-
|0
|-
|1
|-
|2
|-
|3
|-
|4
|-
|5
|}
||
{| border="1"
|+'''FINISH'''
!P1 !!P2 !!P3 !!P4 !!P5
|-
|F||F||F||F||F
|-
|T||F||F||F||F
|-
|T||F||T||F||F
|-
|T||F||T||T||F
|-
|T||T||T||T||F
|-
|T||T||T||T||T
|}
||
{| border="1"
|+'''WORK'''
!R1 !!R2 !!R3 !!R4
|-
|1||1||0||0
|-
|1||1||1||2
|-
|2||4||6||6
|-
|2||10||8||8
|-
|3||14||10||8
|-
|3||14||11||12
|}
||
{| border="1"
|+'''ENTONCES'''
!Puedo Seguir?
|-
|P1 cumple <math>\to</math> Work += Asig[1]
|-
|P3 cumple <math>\to</math> Work += Asig[3]
|-
|P4 cumple <math>\to</math> Work += Asig[4]
|-
|P2 cumple <math>\to</math> Work += Asig[2]
|-
|P5 cumple <math>\to</math> Work += Asig[5]
|-
|'''SUCCESS'''
|}
|}

Por lo tanto, el pedido puede ser satisfecho.

===Ejercicio 8===
Sí. Luego ejecuto '''P1 - P3 - P2'''.

===Ejercicio 9*===
Hay 2 maneras en que es posible que un sistema en estado unsafe no termine en un deadlock. La primera es que alguno de los procesos en ejecución libere alguno de los recursos que estaba utilizando, de manera que otro obtiene todo lo que requería y puede finzalizar satisfactoriamente. Otra posibilidad es que uno de los procesos termine su ejecución sin pedir todo lo que tenía declarado en el MAX, liberando los recursos que estaba consumiendo.

===Ejercicio 10*===
{| class="wikitable" style="text-align:center"
|
{| border="1"
|+'''MAX'''
!Proceso !!R1 !!R2 !!R3 !!R4
|-
! P1
|3||1||1||3
|-
! P2
|3||2||3||4
|-
! P3
|3||3||2||2
|}
|
{| border="1"
|+'''ASIGNACIÓN'''
!Proceso !!R1 !!R2 !!R3 !!R4
|-
! P1
|2||0||0||2
|-
! P2
|0||1||1||0
|-
! P3
|0||1||0||1
|}
|
{| border="1"
|+'''NECESIDAD'''
!Proceso !!R1 !!R2 !!R3 !!R4
|-
! P1
|1||1||1||1
|-
! P2
|3||1||2||4
|-
! P3
|3||2||2||1
|}
|}

a.
Corriendo el algoritmo del banquero:
*Req[1] <math>\le</math> Nec[1]? (0 1 1 1) <math>\le</math> (1 1 1 1) Sí
*Req[1] <math>\le</math> Disp? (0 1 1 1) <math>\le</math> (1 3 3 1) Sí

Entonces se cambian:
*Disp -= Req[1] <math>\to</math> Disp = (1 2 2 0)
*Asig[1] += Req[1] <math>\to</math> Asig[1] = (2 1 1 3)
*Nec[1] -= Req[1] <math>\to</math> Nec[1] = (1 0 0 0)

Corriendo el algoritmo de seguridad:

{| class="wikitable" style="text-align:center"
|
{| border="1"
|+ '''AB'''
!PASO
|-
|0
|-
|1
|-
|2
|-
|3
|}
||
{| border="1"
|+'''FINISH'''
!P1 !!P2 !!P3
|-
|F||F||F
|-
|T||F||F
|-
|T||T||F
|-
|T||T||T
|}
||
{| border="1"
|+'''WORK'''
!R1 !!R2 !!R3 !!R4
|-
|1||3||3||1
|-
|3||4||4||4
|-
|3||4||5||4
|-
|3||5||5||5
|}
||
{| border="1"
|+'''ENTONCES'''
!Puedo Seguir?
|-
|P1 cumple <math>\to</math> Work += Asig[1]
|-
|P2 cumple <math>\to</math> Work += Asig[2]
|-
|P3 cumple <math>\to</math> Work += Asig[3]
|-
|'''SUCCESS'''
|}
|}

Por lo tanto, este pedido puede ser satisfecho.

b.
Corriendo el algoritmo del banquero:
*Req[2] <math>\le</math> Nec[2]? (1 0 0 1) <math>\le</math> (3 1 2 4) Sí
*Req[2] <math>\le</math> Disp? (1 0 0 1) <math>\le</math> (1 3 3 1) Sí

Entonces se cambian:
*Disp -= Req[2] <math>\to</math> Disp = (0 3 3 0)
*Asig[2] += Req[2] <math>\to</math> Asig[2] = (1 1 1 1)
*Nec[2] -= Req[2] <math>\to</math> Nec[2] = (2 1 2 3)

Corriendo el algoritmo de seguridad:

{| class="wikitable" style="text-align:center"
|
{| border="1"
|+ '''AB'''
!PASO
|-
|0
|}
||
{| border="1"
|+'''FINISH'''
!P1 !!P2 !!P3
|-
|F||F||F
|}
||
{| border="1"
|+'''WORK'''
!R1 !!R2 !!R3 !!R4
|-
|0||3||3||0
|}
||
{| border="1"
|+'''ENTONCES'''
!Puedo Seguir?
|-
|'''FAILED'''
|}
|}

Por lo tanto, este pedido '''no''' puede ser satisfecho.

Si esta nueva situación mantiene al sistema en estado "seguro", los recursos son adjudicados. Si el nuevo estado es "inseguro", p(i) debe esperar y, además, se restaura el anterior estado de asignación total de recursos.

===Ejercicio 11*===
a. Si bien es terriblemente ineficiente, tiene la ventaja de que el sistema logra averiguar cómo se cerró el deadlock y puede tratarlo mejor, por lo que elegirlo es una respuesta posible.

b. Puede tardarse bastante tiempo en detectarse el deadlock si el intervalo es muy grande, desperdiciando recursos en el transcurso.

c. Elegir este es lo más correcto, porque se corre el algoritmo una cantidad mínima de veces. Su desventaja es que es muy complicado establecer las cotas de tiempo y rendimiento que equilibren entre no correr el algoritmo muchas veces y no dejar el sistema bloqueado mucho tiempo.

===Ejercicio 12===
El algoritmo del banquiero requiere de ser ejecutado cada vez que se pide un recurso, lo que lo hace ineficiente. Otro problema es que quizas se bloquean muchos procesos para no entrar en estados inseguros, que realmente no terminarian en deadlock, deteriorando mucho la performance del sistema. Además, requiere información sobre los programas (relacuinada con cuánto es el máximo de recursos que van a consumir) que no siempre está disponible.

Por estas razones, en la práctica no se suele utilizar el algoritmo del Banquero. 

===Ejercicio 13*===
a. Secuencia: '''P3 - P4 - P1 - P2'''. Esto significa que si ejecuto los procesos en ese orden, todos los programas terminaran satisfactoriamente.

b. Por que P3 tiene todos los recursos que necesita para finalizar, entonces si existia una secuencia antes, agarro esa secuencia, pongo P3 al principio, y me da una secuencia segura válida para el nuevo estado.

c. No puede ser satisfecho. Porque pide mas recursos de los que la matriz 'necesidad' indica que faltan. Es decir, P4 declaró que usará 1 de ese recurso. La matriz asignación indica que ya se lo otorgué y por lo tanto la necesidad sobre ese recurso queda en cero. Pero P4 vuelve a pedirme una instancia de ese recurso. Por lo tanto se produce un error y se ejecutara alguna rutina del sistema operativo, como por ejemplo eliminar ese proceso del sistema y liberar los recursos que poseía.
NOTESE la diferencia siguiente. P4 NO VA A ESPERA, ya que el error se produjo cuando banquero chequeó las 2 desigualdades pertinentes, y no cuando el algoritmo de seguridad advirtió sobre un paso a un estado UNSAFE. En ese último caso, sí iria a espera P4 y se retrotraerían los valores de las matrices que banquero cambió. En este caso, directamente NO se llega ni a llamar al algoritmo de seguridad. Luego, se CANCELA P4.

===Ejercicio 14*===
#Si los recursos son únicos, estoy en deadlock.
#Si hay mas de una instancia de algún recurso, entonces puede que no, ya que otro proceso que no está en esa espera circular, podría liberar una instancia de uno de los recursos requeridos, rompiendo el círculo.

===Ejercicio 15*===
a.

{| class="wikitable" style="text-align:center"
|
{| border="1"
|+'''ASIGNACIÓN'''
!Proceso !!R1 !!R2 !!R3 !!R4
|-
! P1
|0||1||0||0
|-
! P2
|2||0||0||1
|-
! P3
|3||0||3||0
|-
! P4
|2||1||1||1
|-
! P5
|0||0||2||0
|}
|
{| border="1"
|+'''NECESIDAD'''
!Proceso !!R1 !!R2 !!R3 !!R4
|-
! P1
|0||0||0||0
|-
! P2
|2||0||2||0
|-
! P3
|0||0||0||0
|-
! P4
|1||0||0||0
|-
! P5
|0||0||2||1
|}
|}

Corriendo el algoritmo de seguridad:

{| class="wikitable" style="text-align:center"
|
{| border="1"
|+ '''AB'''
!PASO
|-
|0
|-
|1
|-
|2
|-
|3
|-
|4
|-
|5
|}
||
{| border="1"
|+'''FINISH'''
!P1 !!P2 !!P3 !!P4 !!P5
|-
|F||F||F||F||F
|-
|T||F||F||F||F
|-
|T||F||T||F||F
|-
|T||T||T||F||F
|-
|T||T||T||T||F
|-
|T||T||T||T||T
|}
||
{| border="1"
|+'''WORK'''
!R1 !!R2 !!R3 !!R4
|-
|0||0||0||0
|-
|0||1||0||0
|-
|3||1||3||0
|-
|5||1||5||0
|-
|7||2||6||1
|-
|7||2||8||1
|}
||
{| border="1"
|+'''ENTONCES'''
!Puedo Seguir?
|-
|P1 cumple <math>\to</math> Work += Asig[1]
|-
|P3 cumple <math>\to</math> Work += Asig[3]
|-
|P2 cumple <math>\to</math> Work += Asig[2]
|-
|P4 cumple <math>\to</math> Work += Asig[4]
|-
|P5 cumple <math>\to</math> Work += Asig[5]
|-
|'''SUCCESS'''
|}
|}

b. Hay que aplicar Shoshani-Coffman.


[[Category:Prácticas]]