\newpage # Ejercicio 9 Implementamos este ejercicio utilizando: * `Map` * `vector>` Donde pid es `unsigned int`. Esto nos permite: * Poder mantener cada cola de prioridad con los PIDs que tiene asignados. * Acceso fácil/rápido al estado de cada proceso por su PID. En dicho `Map` se almacena un `struct` con datos del proceso actual como: _pid_, _state_ y *quantum_count*, a los que se accede utilizando el _pid_ como clave. En el constructor se leen los parámetros que recibe la cantidad de ticks a asignar por quantum a cada cola (esto le da la 'prioridad' a cada cola). Cada vez que se carga un nuevo proceso, el mismo se aloja en la cola de mayor prioridad. Al haber un _tick_ se controla que no se haya cumplido el _quantum_ establecido para dicha cola, si se cumplió se lo intenta mover a una cola de menor prioridad (de existir) y se marca como READY. Al haber un _unblock_ se intenta "premiar" a la tarea (que no utilizó completamente su quantum antes de ser desalojada), moviéndola a una cola de mayor prioridad. ![Ejercicio 9 - CPU](informe/imagenes/ejercicio9_gantt_casos_1.png) ![Ejercicio 9 - CPU Heavy + IO](informe/imagenes/ejercicio9_gantt_casos_2.png) ![Ejercicio 9 - CPU Esporadico + IO Heavy](informe/imagenes/ejercicio9_gantt_casos_3.png) ![Ejercicio 9 - Interactivo](informe/imagenes/ejercicio9_gantt_casos_4.png) ![Lotes: CPU | CPU Heavy + IO | CPU esporadico + Heavy IO | Interactivo](informe/imagenes/caso_mfq_4_gral.png) Se puede observar que este scheduler es *muy* ineficiente para casos en los que se utiliza mucho CPU y poco IO; todas las tareas quedan en la cola de menor prioridad y sucede lo mismo que vimos en el scheduler RR: la relación quantum / context switch es muy mala. Observación: Este scheduler debería ser 'bueno' para tareas interactivas pero esto no se da ya que al tener una implementación ingenua sin `CPU Pinning` perdemos mucho tiempo cuando las tareas cambian de core. \newpage # Definiciones * Latencia: Cantidad de ticks en ready hasta que se ejecuta la primera task. Esta métrica se puede extender para ver la latencia promedio de todos los procesos que corrió el scheduler. * Waiting time: Cantidad de ticks en ready durante toda la ejecución de un proceso. * Tiempo total de ejecución / Turn around time: Intervalo de ticks desde que se ejecuta un proceso hasta su terminación. No incluye latencia. * Throughput : Numero de procesos completado por el sistema por unidad de tiempo.