Seguimos buscando a Arshak. Ayudanos compartiendo!
Encuesta no oficial de docentes
Resultados de la encuesta no oficial de docentes
Probaste el SIGA Helper?

Donar $100 Donar $200 Donar $500 Donar mensualmente


Enviar respuesta 
 
Calificación:
  • 0 votos - 0 Media
  • 1
  • 2
  • 3
  • 4
  • 5
Buscar en el tema
[APORTE] Final Sistemas Operativos 30/07/2019
Autor Mensaje
Mauro_bilo Sin conexión
Campeon del cubo Rubik
Tool
****

Ing. en Sistemas
Facultad Regional Buenos Aires

Mensajes: 123
Agradecimientos dados: 139
Agradecimientos: 46 en 23 posts
Registro en: Sep 2010
BlogSpot Facebook LinkedIn
Mensaje: #1
[APORTE] Final Sistemas Operativos 30/07/2019 Finales Sistemas Operativos
Bueno gente, pasado un día de la felicidad extrema que produce aprobar esta materia karma y de la que no le deseo ni a mi peor enemigo tener que prepararla, les cuento un poco de lo que recuerdo que se tomó ayer.

Como siempre, la estructura fue la misma, dos prácticos (aunque uno fue más bien teórico) y 5 preguntas teóricas VoF a desarrollar.

Preguntas teóricas (el orden no se respeta):

1) La única manera de evitar la monopolización de la CPU es mediante interrupciones.
-Puse FALSO, argumentando que el mismo proceso podía abandonar la CPU. Me lo pusieron bien aunque me hicieron un comentario.

2) La segmentación paginada produce mayor fragmentación interna que segmentación y paginación, sin embargo permite un mejor aprovechamiento de la memoria.
-FALSO, Es cierto que hace un mejor manejo de la memoria y que posee mayor fragmentación interna que en segmentación, PERO posee la misma fragmentación interna que en paginación que sería la porción de la última página.

3) Si se tiene dos FS UFS, y se intenta pasar el contenido de uno a otro utilizando un pendrive formateado con FAT32, habrá información que se perderá.
-VERDADERO. Debido a que UFS permite almacenar mayor metadata que FAT32 no. Entonces, al hacer el copia de la info al pendrive, dicha metadata se pierde.

4) Si dos procesos que comparten recursos y no utilizan semaforos mutex para proteger la región crítica, si al menos uno de ellos modifica el recurso entonces habrá condición de carrera.
-Como siempre, tenés que estar super atento a la forma en que se arman las oraciones. Yo justifiqué que si sólo uno modifica el recurso entonces no habrá condición de carrera debido a que siempre ambos procesos van a leer el resultado correcto, pero creo que me lo pusieron mal.

5) [No la recuerdo muy bien] Era algo respecto del jacketing en el uso de ULT's y el context switch.


La parte teórica me pareció que se podía hacer si habías estudiado mucho, contrario a otras veces que no sabes para donde rajar.
---------------------------------------------------------------------------------------------------------------------------------------------------------------------
[PRACTICA]
La verdad que estuvo brava y zafé solo por el hecho que pude hacer bien el primero de ambos. Les cuento que onda:

1) Ejercicio de planificación con sincronización de procesos corriendo concurrentemente. Había hecho un ejercicio de este tipo creo que el día antes y recordé algunas cosas teóricas que de no haberlo hecho, no hubiese podido resolverlo correctamente.
Eran 3 procesos, dos de los cuales ejecutaban 2 instancias cada uno, es decir, habíua que planificar 5 procesos en el gantt de los cuales se veía el código y comenzaba con un while(1) { //codigo }, y dentro de ese código tenía distintos wait() y signal() sobre distintos semáforos (tanto mutex como contadores). Te pedían simular hasta t=35, se planificaba con RR con q=2, y ponian varios comentarios:
* Las llamadas al sistema wait() y signal() eran atómicas mediante la deshabilitación de interrupciones y ocupaban 3 UT. Con esto, querían que te avivaras de que por más que el q=2, cada vez que se ejecutaba una de estas sentencias, debias exceder el tiempo de quantum.
* Las instrucciones condicionales ocupaban 1 UT. Acá creo que muuuuchos deben haber metido la gamba y casi lo hago yo también. Como el código arrancaba con un while(1), en el primer instante se corria 1UT por el while y después se ejecutaban los wait/signal. Eso hacía que te quedaran las primeras ráfagas de 4UT.
* Te decía además que el desbloqueo por signal tenía mayor prioridad que por IO (no había IO en el ejercicio, lo que te llenaba de dudas mal) y menos que por Q. Eso te quería decir que cuando ejecutaras un Signal(X), si ese X tenía un proceso bloqueado previamente, tenías que ponerlo DESPUÉS del que volvía por Q.
* Después decía una fruta de que si se ejecutaba una función que no retornaba ningún valor o no se podía ejecutar por el parámetro, producía un error que finalizaba el proceso. Esto no lo usé para nada, es esa info para confundirte y hacerte dudar.

Habia que ser muy cuidadoso con las instrucciones ejecutadas debido a que 2 de los procesos tenían dos instancias y también con los valores de los semáforos para determinar los bloqueos y eso. Respecto a la planificación, teniendo en cuenta el tema de que las instrucciones atómicas no se interrumpían, iba saliendo.
Me terminaban quedando P1 y P2 en ready/running (ambos del proceso P), y los otros D1, D2 y M, bloqueados. Ningún proceso me finalizaba porque al simular hasta el t=35 era una porción de todo el código. Otra cosa que generaba muchas dudas.

Sólo eso, era el punto a), el punto b) pedía buscar errores en la sincronización en cada proceso. Había varios, variables mal inicializados, secciones críticas no bien cubiertas, secciones de código que dependian de un IF y que podían llevar a un bloqueo. Este punto era más sencillo que el anterior.

Si bien lo pude hacer, me dejó la cabeza re limada. Me pareció un ejercicio dificil por todas las condiciones que tenía.


2) Ejercicio de file system más bien teórico. Lo hice mal según lo que me pusieron en el examen, pero les cuento que onda.
Contaba que había un disco rígido de 20gb con bloques de 4kb, donde se habían utilizando 2gb para almacenar un archivo y además sobraban 4gb de espacio libre. En un momento se producían daños en el disco pero que estos no impedían que se pudiera acceder al archivo al menos por un tiempo (esto no recuerdo si era así tal cual). Comentaba además que luego, se intentaba guardar otro archivo y demoraba algo más por alguna tarea administrativa, y que finalmente guardaba correctamente.

a) Que tipo de asignación se había utilizado y se debía justificar porque se descartaban las otras opciones. Yo puse indexada, pero creo que era contigua. Había que justificarlo con el tema de que continuó funcionando a pesar de tener bloques dañados.

b) Cuantos accesos a disco y estructuras necesitaban ser leídas para acceder al bloque 312 del archivo. No tuve NI IDEA que hacer ahi.

c) Si otro proceso quiere acceder a leer determinados bloques y este es impedido de relizar tal tarea. Que herramientas de mutua exclusión podrían estar siendo utilizadas. Yo puse locks de escritura, pero no recuerdo si me sumó un puchito. Había que ser holgado en la justificación ya que se pedía ser detallado.

d) Sabiendo que el tamaño de los bloques de punteros eran de 4 bytes, pedían el tamaño real.
Lo que yo hice fue dividir 20gb/4kb = cantidad de bloques. A cada bloque le restaba los 4 bytes, y me quedaba que los bloques de datos eran 4092 bytes. Mutipliqué ambas cosas y me daba algo de 19,98Gb. Pero se ve que me faltó algo más.

Como dije, no supe mucho para donde rajar con este ejercicio. La bronca es que yo sabía que iba a entrar FS y te MATAS haciendo ejercicios de FAT e i-nodos, para que después te entra algo super teórico. Algo similar me había pasado en el punto 1) de la mesa de mayo donde me bocharon.
--------------------------------------------------------------------------------------------------------------------------------------------------

En fin, se terminó para mi, pero no para muchos de uds. Quise aportar mi granito de arena contando que onda el final y que después se pueda adjuntar acá para poder discurtirlo con los que lo necesiten. Me han ayudado mucho a prepararlo este tipo de post así que acá está mi parte.

Como comentario final, diría que estoy un poco en desacuerdo en la forma que se evalúa la materia, en la que se vuelve la SUERTE un factor importantísimo, ya que jamás podés inferir que te van a tomar, y podés MATARTE estudiando y aún así terminar desaprobando o aprobar de pedo como en mi caso. Doy fe de que nunca en toda mi carrera que ya esta llegando a su fin, estudié tanto como para este final y sólo así me alcanzó para zafar. No aflojen porque es la única manera posible.

Estoy a su disposición,
Saludos!
(Este mensaje fue modificado por última vez en: 31-07-2019 20:37 por Mauro_bilo.)
31-07-2019 19:57
Envíale un email Encuentra todos sus mensajes Agregar agradecimiento Cita este mensaje en tu respuesta
[-] Mauro_bilo recibio 3 Gracias por este post
CarooLina (31-07-2019), heinn (08-08-2019), reLlene (06-11-2019)
Julian.O Sin conexión
Militante
ing :)
***

Ing. en Sistemas
Facultad Regional Buenos Aires

Mensajes: 50
Agradecimientos dados: 91
Agradecimientos: 154 en 35 posts
Registro en: Apr 2016
Mensaje: #2
RE: [APORTE] Final Sistemas Operativos 30/07/2019
Buenas! Te completo con lo que me acuerdo del practico 2

a) Era contiguo, la clave era darse cuenta que el tiempo que demoraba cuando quería guardar el archivo nuevo era porque estaba compactando, la verdad eso estaba re confuso, muy difícil avivarse.

d) Tamaño de bloque 4Kb, Punteros de 4 bytes = 32 bits, entonces tenes 2³² bloques x 2¹² = 16 TB
Minimo entre real(20gb) y teorico(16TB) = 20Gb
01-08-2019 09:03
Encuentra todos sus mensajes Agregar agradecimiento Cita este mensaje en tu respuesta
[-] Julian.O recibio 1 Gracias por este post
Mauro_bilo (01-08-2019)
Mauro_bilo Sin conexión
Campeon del cubo Rubik
Tool
****

Ing. en Sistemas
Facultad Regional Buenos Aires

Mensajes: 123
Agradecimientos dados: 139
Agradecimientos: 46 en 23 posts
Registro en: Sep 2010
BlogSpot Facebook LinkedIn
Mensaje: #3
RE: [APORTE] Final Sistemas Operativos 30/07/2019
Claro, viendo lo que hiciste se ve que jamás me di cuenta que el File System era FAT 32. Te acordas como fue que llegaste a eso?

Por otro lado, lo de la demora y que estuviera compactando es un chiste. Felicito al tipo que se dió cuenta de eso. En estas cosas son las que yo opino que se evalúa mal.
(01-08-2019 09:03)Julian.O escribió:  Buenas! Te completo con lo que me acuerdo del practico 2

a) Era contiguo, la clave era darse cuenta que el tiempo que demoraba cuando quería guardar el archivo nuevo era porque estaba compactando, la verdad eso estaba re confuso, muy difícil avivarse.

d) Tamaño de bloque 4Kb, Punteros de 4 bytes = 32 bits, entonces tenes 2³² bloques x 2¹² = 16 TB
Minimo entre real(20gb) y teorico(16TB) = 20Gb
(Este mensaje fue modificado por última vez en: 01-08-2019 14:15 por Mauro_bilo.)
01-08-2019 11:39
Envíale un email Encuentra todos sus mensajes Agregar agradecimiento Cita este mensaje en tu respuesta
verne Sin conexión
Militante
Así soy yo
***

Ing. en Sistemas
Facultad Regional Buenos Aires

Mensajes: 76
Agradecimientos dados: 8
Agradecimientos: 14 en 8 posts
Registro en: Oct 2013
Mensaje: #4
RE: [APORTE] Final Sistemas Operativos 30/07/2019
Originalmente me habían puesto un 4, discutí un poco los puntos teóricos que para mi estaban mal corregidos y me pusieron un seis. Todavía no lo creo.

Como muchos, el ejercicio 2) de práctico no lo pude resolver, ya estaba mega quemado del 1).

Respecto al ejer 1) del práctico... Habré hecho 30 ejercicios de planificación con muchas combinaciones y nunca había hecho uno tan raro. Al principio daba miedo, pero a medida que lo ibas resolviendo te dabas cuenta que no era tan jodido. Tuve mucha suerte con presunciones que hice y tuve que aprender a lidiar con que algunos "tips" que daban, ni los llegabas a usar, eso me confundía aún más.

Coincido con lo que dijeron, es muy triste que una materia tan clave en el avance de la carrera tenga un factor de suerte altísimo en el final. Yo la preparé en 1 semana, una materia que cursé hace como 4 años... Debe haber gente que la preparó 3 meses, pero la suerte no la acompañó en este final...

Volverte loco es síntoma de la enfermedad del progreso.
08-08-2019 18:09
Encuentra todos sus mensajes Agregar agradecimiento Cita este mensaje en tu respuesta
[-] verne recibio 2 Gracias por este post
Mauro_bilo (12-08-2019), heinn (28-01-2020)
heinn Sin conexión
Campeon del cubo Rubik
ingeniería en sistemas
****

Ing. en Sistemas
Facultad Regional Buenos Aires

Mensajes: 184
Agradecimientos dados: 758
Agradecimientos: 64 en 30 posts
Registro en: Mar 2017
Mensaje: #5
RE: [APORTE] Final Sistemas Operativos 30/07/2019
Que onda la revision del examen? Es que ningún final que di yo me muestran el examen, hay que pedirlo.
08-08-2019 21:51
Encuentra todos sus mensajes Agregar agradecimiento Cita este mensaje en tu respuesta
Buscar en el tema
Enviar respuesta 




Usuario(s) navegando en este tema: 1 invitado(s)