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
Final Sisop Mayo
Autor Mensaje
Ricitos Sin conexión
Secretario General
Sin estado :(
*******

Ing. en Sistemas
Facultad Regional Buenos Aires

Mensajes: 736
Agradecimientos dados: 9
Agradecimientos: 16 en 10 posts
Registro en: Apr 2008
Mensaje: #1
Final Sisop Mayo Finales Sistemas Operativos
Hola:
Alguien me puede contar como fue el final de hoy de operativos ?
GRacias !
28-05-2008 23:04
Encuentra todos sus mensajes Agregar agradecimiento Cita este mensaje en tu respuesta
pablo Sin conexión
ModdIng
Hombre de ingenio (?)
********

Ing. en Sistemas
Facultad Regional Buenos Aires

Mensajes: 1.637
Agradecimientos dados: 0
Agradecimientos: 24 en 14 posts
Registro en: Apr 2008
Mensaje: #2
Re: Final Sisop Mayo
Te comento bastante lo que me acuerdo, y cómo lo resolví.

Teoría (V ó F): (bastante fácil con respecto a otros finales... al menos creo que no eran tan ambiguos o sin sentido como otros que vi)

1) Deshabilitar las interrupciones en un sistema multiprocesador soluciona el problema de la región crítica. (puse F, pues se sabe que en estos sistemas esa opción se pierde).

2) Durante la espera activa (busy waiting) el sistema no hace nada (o algo así decía) mientras espera para entrar en la región crítica. (puse F, porque Busy Waoiting también se usa para esperar el fin de una I/O, pero ellos pusieron que es F porque en realidad sí hace "algo", procesa, y ahí dice que no hace nada... las típicas hiladas finas de operativos U_U).

3) Si el grado de multiprogramación en un sistema es alto, es más probable que se produzca trashing, por lo cual será necesario reducir el working set. (o algo así, no recuerdo, no te confíes tanto en cómo lo expreso porque el valor de verdad del enunciado puede depender de alguno de esos detalles). (puse V, pues al haber más procesos en memoria a cada uno le corresponden menos frames y por lo tanto se debe usar más swapping para llevar y traer páginas de memoria virtual... el trashing era cuando el sistema estaba más tiempo haciendo esto que procesando código de usuario).

4) El RAID 1 es más costoso que el RAID 0 pero posee la misma performance. (puse F, porque si bien es más costoso permite mayor performance ya que posee discos espejados mientras que el 0 sólo los agrupa pero no tiene redundancia).

5) La asignación de bloques en disco evita la fragmentación interna. (puse F, porque no la evita, un bloque asignado puede tener espacio sin usar, por ejemplo si el registro de datos que se cargó en él es de tamaño menor. Ellos lo justificaron diciendo que lo que no evita es la fragmentación externa, algo así, pero eso tampoco sería útil para justificarla).

Prácticos:

1) Memoria paginada. Conjunto de solicitudes a páginas. Determinar cantidad de Page Faults:
a. FIFO con 2 frames de memoria.
b. LRU con 3 frames de memoria.

Bastante accesible. No tenías ni siquiera que calcular las páginas, ya venían dadas. Lo único es que indicaba la cantidad de frames diciendo "el working set es de 2" (en el "a") y eso es confuso, porque si no me equivoco el working set era el grado de multiprogramación del sistema (cuántos procesos en memoria simultáneamente) y no la cantidad de frames asignados por proceso. Si fuera así, el dato no se podría usar, porque ni siquiera se indicaba si el alcance del reemplazo era local o global.

2) Planificación. Colas multinivel. Una Cola 1 que planifica RR con Q=2 y otra Cola 2 que planifica RR con Q=3, de mayor prioridad. Grado de multiprogramación = 3. Cuatro procesos para planificar, con una ráfaga de CPU, una de I/O y otra de CPU. El proceso 3 ejecutaba instrucciones atómicas de 4 unidades de tiempo.
Los procesos ingresaban a la Cola 1. Si se acababa el Quantum volvía a la cola 1. Al bloquearse, pasaban a la 2 cuando volvían de I/O. No podía haber más de 3 procesos ejecutando a la vez (por el grado de multiprogramación).
Objetivo: determinar tiempos de finalización de cada proceso.

Bastante accesible en comparación a otros de planificación. A veces te mareabas un poco pero se podía sacar, no había nada que quedara en duda si conocías las prioridades de interrupciones y demás.

3) Semáforos. 3 procesos o hilos concurrentes. Los tres procesos debían llegar a un punto X, y no empezar a ejecutar desde ahí hasta que los tres hubieran llegado. Después, el segundo y tercer proceso debían hacer lo mismo con un punto posterior Y. Como siempre, no se debía producir ni Deadlock (interbloqueo) ni Starvation (inanición).
Bastante fácil también. Si probabas con semáforos intuitivamente y hacías la prueba, te dabas cuenta que funcionaba bien, pero no era complicado lograrlo.


Ojo, todas te las respondí en base a lo que hice yo, considerá que me saqué un 6, pero no sé en qué me equivoqué (igual no creo que en mucho porque no te podés equivocar en muchas cosas porque si no te bochan, más en un final así supongo).
El final era bastante accesible, y lo dijeron de entrada (y con un poco de anticipación en días), por eso me presenté. La verdad que ni siquiera era mi intención unos 5 días antes, pero la preparé rápido y más que nada me puse con la práctica; igual considera que lo había dado mal dos veces y me había levantado otras dos).


Cualquier cosa después te paso parte de mis resoluciones si querés porque me las guardé y las debo tener por ahí aún. =P

Mucha suerte!
03-06-2008 12:14
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)