UTNianos

Buenas!!

Alguien tiene para compartir el final de operativos tomado el día de ayer 16/07???

Desde ya muchas gracias.

Saludos.

Teoria:
1) Un sistema el cual sufre del problema de inversion de prioridades se podria solucionar si se aplica como estrategia el algoritmo de planificacion VRR.
Yo puse FALSO, y justifique que vos podias tener 2 procesos mal sincronizados independientemente del algoritmo de planificacion utilices.
Pero era VERDADERO, porque para que se de el problema de inversion de prioridades (cuando un proceso de menor prioridad no deja que otro de mayor prioridad se ejecute), justamente esa prioridad la almacenas en algun lado --> en el algoritmo de planificacion, y en este caso si usas VRR no sufre inanicion por lo que el problema se soluciona.
2) Te decia algo asi como que un esquema de FS con memoria continua podria ser accedido en "ciertos casos" con igual rapidez que uno con FAT
Yo puse VERDADERO, y justifique con que si bien FAT manejaba bloques enlazados, FAT lo que hace es una modificacion a ese esquema, cargando en memoria la tabla FAT que le permite tener la estructura de los encadenamientos para poder recorrer los bloques de manera mas rapida, y que en "ciertos casos" podria llegar a ser igual
Pero entiendo que era FALSO, porque esa estructura de encadenamiento de alguna manera te mete overhead por lo que entendi que me comento el profe
3) Un sistema con un solo procesador no muy potente, con muchos recursos y con la necesidad de que nunca se genere un deadlock, la mejor estrategia es utilizar EVASION
FALSO, porque si bien es verdad que con evasion nunca se va a generar de deadlock, aca estas limitado por el procesador que no es potente y por la gran cantidad de recursos. Por lo tanto lo mejor seria usar PREVENCION que tiene menos overhead y tambien cumple con la condicion de que nunca se genere deadlock. Ademas de que en PREVENCION vos definis las politicas una vez y no es como EVASION que tenes que estar corriendo el algoritmo del banquero con cada solicitud
4) Los KLTs puede sufrir de memory leaks porque la estructura de TCB no comparte el heap del proceso
FALSO, lo que no comparten los TCB es el stack, pero si comparten datos, codigo y heap
5) Las E/S sincronas siempre son bloqueantes
FALSO, las sincronas como las asincronas pueden ser bloqueantes o no bloqueantes, tenias que dar un ejemplo de una E/S no bloqueante


Practica:
1) Segmentacion paginada con memoria virtual, muy parecido al que comentamos hoy, y la estructura de las direcciones logicas y fisicas de hecho era la misma, pero le sumaba una TLB con la particularidad que los campos que tenia era DIR y FRAME, por lo que te tenias que avivar que DIR era la composicion de #segmento y #pagina. Pero no tenias que darle tanta vuelta con los reemplazos de marcos, te daba 3 direcciones logicas que las tenias que pasar a direcciones fisicas. Ademas los segmentos tenian diferentes permisos y todas las direcciones logicas eran de escritura, la 1) te daba un segmento valido pero un #pagina "invalido", pero haciendo la traduccion de DIR, sacabas que estaba en la TLB. la 2) te daba SEGMENTATION FAULT y la 3) te daba en un segmento que no tenia permisos de escritura por lo tanto era invalida por permisos

2) Un problema tipico y bastante sencillo de sincronizacion, donde tenias 3 procesos, uno leia reportes(10 instancias) otro generaba reportes (100 instancias) y otro era una base de datos (1 instancia). Entonces te decia que el que generaba reportes se conectaba a la base de datos, tenias un limite de 10 conexiones, que generaba una query que la mandaba la db y que cuando la db le devolvia la metia en un archivo de reportes que aclaraba que era el unico recurso compartido en el sistema (le tenias que meter un mutex). Te decia que las lecturas solian tardar como 1 hora pero que las escrituras estaban optimizadas para durar poco tiempo, algo asi.
a) sincronizar mediante semaforos
b) te decia si podias utilizar algun otro mecanismo de sincronizacion, donde y porque


*** Dejo adjunto el parcial al que hago referencia

Saludos

Groso Seba, +10 a todo lo que dijo Seba.

Agrego esto nomas en la teoría:
2- Falso, porque al ser asignación contigua, vos directamente con 1 dirección y sabiendo cuanto mas, ya te traes todos los bloques.
En cambio en FAT, deberías ir accediendo siempre de a 1 para ir a buscar la próxima dirección.


Acá dejo una copia del final :D

Buenas!!

Aporto mi resolución práctica para que alguno pueda compararlo y ver que onda:

1) Por los datos, tenemos que son 12 b para marcos (4 KB), 2 b para segmentos (no más de 4) y 2 para páginas (es el resto).

3C38 h = segmento 0 pagina 3, la pagina es invalida pero como dice Seba, en la TLB entiendo que el segundo registro es el que nos aplica (seg 0 + pagina 3 = 3 ) entonces sabemos que es Frame 1. --------> Dir Fis: 1C38 h.

FFAC h= seg 3 pag 3, Segmentation Fault.

AA00 h = seg 2 pag 2, pero como el segmento es solo R, da error de permisos. Sino entiendo que sería PF y habría que ver cual reemplazar.

2) Dejo como entiendo que debería quedar:



Si alguno puede aportar los puntos b de cada ejer, se lo agradezco.

Espero que alguno pueda chequearlo y corregir lo que esté mal.
Saludos!!

---

(24-09-2019 17:18)Becaxs escribió: [ -> ]Buenas!!

Aporto mi resolución práctica para que alguno pueda compararlo y ver que onda:

1) Por los datos, tenemos que son 12 b para marcos (4 KB), 2 b para segmentos (no más de 4) y 2 para páginas (es el resto).

3C38 h = segmento 0 pagina 3, la pagina es invalida pero como dice Seba, en la TLB entiendo que el segundo registro es el que nos aplica (seg 0 + pagina 3 = 3 ) entonces sabemos que es Frame 1. --------> Dir Fis: 1C38 h.

FFAC h= seg 3 pag 3, Segmentation Fault.

AA00 h = seg 2 pag 2, pero como el segmento es solo R, da error de permisos. Sino entiendo que sería PF y habría que ver cual reemplazar.

2) Dejo como entiendo que debería quedar:



Si alguno puede aportar los puntos b de cada ejer, se lo agradezco.

Espero que alguno pueda chequearlo y corregir lo que esté mal.
Saludos!!

Recién acabo de ver que están subidas las respuestas. Las dejo por si alguien no las tiene.
Saludos!