3. ARQUITECTURA DE UN SISTEMA OPERATIVO

¿Qué es un sistema operativo?

Un sistema operativo es el programa que oculta la verdad del hardware al programador y presenta una vista simple y agradable de los archivos nominados que pueden leerse y escribirse. El sistema operativo resguarda al programador del hardware del disco y presenta una interfaz simple orientada al archivo, también disimula mucho del trabajo concerniente a interrupciones, relojes o cronómetros, manejo de memoria y otras características de bajo nivel.

La función del sistema operativo es la de presentar al usuario con el equivalente de una máquina ampliada o máquina virtual que sea más fácil de programar que el hardware implícito.

Un sistema operativo es una parte importante de casi cualquier sistema de computación. Un sistema de computación puede dividirse en cuatro componentes: el hardware, el sistema operativo, los programas de aplicación y los usuarios.

El núcleo

El núcleo es la componente del sistema operativo que siempre está residente en la memoria real del computador. La función primordial del núcleo es transformar los recursos reales del computador en recursos estándares y cómodos de usar.

Es así como el núcleo transforma un procesador real con su memoria finita en un número prácticamente ilimitado de procesadores virtuales o procesos. Cada proceso dispone de su propio tiempo de CPU, una memoria extensible y mecanismos estándares para interactuar con los dispositivos, sin importar los detalles físicos de su implementación.

La API del núcleo

Una API (Interfaz de Programación de Aplicaciones) es el conjunto de servicios que ofrece un sistema a las aplicaciones usuarias de ese sistema. Las aplicaciones invocan estos servicios a través de llamadas a procedimientos. La API queda definida por lo tanto por los nombres de estos procedimientos, sus argumentos y el significado de cada uno de ellos.

El conjunto de servicios que ofrece el núcleo a los procesos se denomina la API del núcleo. Está formada por procedimientos pertenecientes al núcleo, pero que se

invocan desde un proceso cualquiera. La invocación de uno de estos procedimientos es una llamada al sistema.

Ejemplos de llamadas al sistema en Unix son:

Manejo de Procesos: creación ( fork), destrucción ( kill), término ( exit), sincronización ( wait), carga de un binario ( exec).

Manejo de memoria: extensión de la memoria de datos ( sbrk).

Manejo de archivos y dispositivos: open, read, write y close.

Estas llamadas se implementan usualmente con una instrucción de máquina que provoca una interrupción. Esta interrupción hace que el procesador real pase a modo sistema e invoque una rutina de atención perteneciente al núcleo y que ejecuta la llamada al sistema. Los argumentos de la llamada se pasan a través de los registros del procesador.

Los drivers para dispositivos

La operación de los dispositivos es altamente dependiente de su implementación. Es así como un disco SCSI se opera de una forma distinta de un disco IDE. Para independizar el código del núcleo de los variados mecanismos de interacción con los dispositivos, el núcleo define clases de dispositivos. Ejemplos de clases son disco, cinta, puerta de comunicación, interfaz de red, etc. Para cada clase se define una interfaz estándar para interactuar con cualquier dispositivo que pertenezca a la clase. Esta interfaz corresponde a las declaraciones de un conjunto de procedimientos no implementados.

Un driver es el código que implementa una interfaz estándar para interactuar con un dispositivo específico, como por ejemplo un disco SCSI. Este código es por lo tanto altamente dependiente de los discos SCSI y no funcionará con discos IDE. Sin embargo, el núcleo interactúa con este driver para discos SCSI de la misma forma que lo hace con el driver para discos IDE, es decir a través de la misma interfaz.

La visión que tiene el núcleo de un disco a través de un driver es la de un arreglo de bloques de 512 o 1024 bytes de taman o fijo. El núcleo puede leer o escribir directamente cualquiera de estos bloques haciendo uso de la interfaz estándar de la clase disco.

Por otra parte, la visión que tiene el núcleo de una cinta es la de un conjunto de bloques de taman o variable que sólo pueden leerse o grabarse en secuencia.

También puede rebobinar esta cinta para volver a leerla o grabarla. Todo esto a través de la interfaz estándar de la clase cinta.

En Unix una aplicación puede accesar una partición de un disco en su formato nativo abriendo por ejemplo /dev/sd0a.

Es usual que los drivers estén siempre residentes en la memoria real y por lo tanto son parte del núcleo. Sin embargo la tendencia es que los drivers son módulos que se cargan dinámicamente si es necesario. También existen drivers que corren como un proceso --como cualquier aplicación-- y por lo tanto corren en modo usuario (por ejemplo el servidor X de X-windows).

El sistema de archivos

El sistema de archivos es la componente del sistema operativo que estructura un disco en una jerarquía de directorios y archivos. Conceptualmente multiplexa un disco de taman o fijo en una jerarquía de discos de taman o variable o archivos.

Dada esta equivalencia conceptual entre discos y archivos no es raro que ambos se manipulen con las mismas llamadas al sistema: open, read, write, close y lseek (esta última mueve la cabeza del disco hacia un bloque determinado).

Es usual que el sistema de archivos sea parte del núcleo. Por lo demás la motivación inicial de muchos sistemas operativos como Unix era el de ofrecer un sistema de archivos a un único proceso. Por algo DOS significaDisk Operating System y por ello es natural que forme parte del núcleo. Sin embargo hay sistemas operativos que ofrecen el sistema de archivos como parte de un proceso que no es parte del núcleo.

El intérprete de comandos

El intérprete de comando (o shell) se encarga de leer las órdenes interactivas del usuario y ejecutar los programas que el usuario indique.

Usualmente el intérprete de comandos es un proceso más del sistema operativo y no forma parte del núcleo. Por ejemplo Unix ofrece varios intérpretes de comandos ( sh, csh y sus variantes). El intérprete de comandos de DOS se encuentra en COMMAND.COM.

Ejemplos de Sistemas Operativos

A continuación revisamos la estructura de algunos sistemas operativos.

DOS

En sus primeras 3 versiones, DOS era realmente un monitor residente que se

situaba entre una aplicación y el Hardware/ROM de un PC (ver figura  ). Los objetivos del sistema no eran ambiciosos puesto que debía correr en computadores con poca memoria.

    Figure: Organización del Software en un PC

El núcleo de DOS implementaba un sistema de archivos jerárquico y da acceso a puertas seriales y paralelas. El sistema es estrictamente mono-proceso y la memoria se limita a los primeros 640 KBytes de la memoria descontando lo que ocupa el mismo DOS. Un programa puede llamar a la API de DOS a través de la instrucción de máquina INT que provoca una interrupción.

Dado que la Intel 8088 no ofrecía modo dual ni mecanismos para implementar espacios de direcciones virtuales, tanto DOS como el proceso en ejecución corren en el mismo modo y espacio de direcciones. Esto no es un problema en un sistema mono-usuario y mono-proceso y que por lo tanto no necesita un mecanismo de protección.

Los drivers no son parte de DOS, sino que vienen en la memoria ROM de un PC. Esta componente se llama BIOS (Basic Input Output System) y puede ser invocada directamente por la aplicación sin pasar por DOS. Lamentablemente la BIOS no incluye los drivers suficientemente generales para manejar apropiadamente los distintos dispositivos. Esto obliga a que las aplicaciones deban accesar directamente el hardware para operaciones tan simples como dibujar una línea en la pantalla.

Hoy en día DOS sí implementa en una forma rudimentaria múltiples procesos, cada uno en su propio espacio de direcciones. Sin embargo DOS debe permitir que estos manipulen directamente los dispositivos (sin hacerlo a través de DOS) para garantizar la compatibilidad con las antiguas aplicaciones. Por ello DOS no puede ofrecer verdadera protección entre procesos.

Linux, Berkeley Unix y Unix System V release 3.X

Todas estas variantes de Unix tienen estructura similar (ver figura  ). El núcleo incluye los drivers y el sistema de archivos.

    Figure: Estructura de un Sistema Unix tradicional.

Además de los servicios de la API del núcleo, Unix ofrece muchísimos otros servicios a través de procesos demonios, que corresponden a procesos que siempre están corriendo. Entre estos se cuentan los servicios de spooling, mail, news, www, etc.

Chorus y Mach

El núcleo de estos sistemas operativos está disen ado con el enfoque minimalista: sólo ofrece el servicio de manejo de procesos e intercomunicación entre procesos a través de una API no estándar. El sistema de archivos, los drivers y cualquier otro servicio queda fuera del núcleo y son ofrecidos por medio de procesos.

Ambos sistemas son compatibles con Unix System V gracias a un proceso que implementa la API estándar de Unix. Las llamadas de sistema de un proceso Unix se implementan enviando mensajes al proceso de la API que ejecuta la llamada y devuelve el resultado en otro mensaje.

El interés de este tipo de sistemas es que pueden implementar varias APIs no sólo la de Unix, sino que también la de Windows o la de Macintosh, etc., cada una de estas APIs se implementan en procesos independientes

3.1 MANEJO DEL PROCESADOR

Administración del procesador (Scheduling)

LA IDEA principal de la administración del procesador tiene que ver con el tiempo que permanecerá un proceso en el procesador, ¿Qué proceso corre en que momento?

En un computador personal es mas dificil encontrar el caso que u usuario necesite ejecutar dos procesos al mismo tiempo, enviar un correo y escribir un texto.

Mientras que en un servidor esta clase de ejecuciones es constante.

Para eso se necesita realizar planificación del procesador.

Planificación del procesador

La tarea del planificador es hacer que un proceso dentro del procesador pase a la “lista de procesos listos”.

la “lista de procesos listos” no es una FIFO.

El planificador se ejecuta cuando:

- Se crea ose termina un proceso

- Un proceso realiza una llamada al sistema (syscall). Pasa de “corriendo” a “esperando”.

- Un proceso pasa de “corriendo” a “listo”. (ej: interrupción de hardware).

- Un proceso que pasa de “esperando“ a ”listo” (ej: interrupción de hardware).

Tipos de planificación

SO no expropiativo (non-premptive): El planificador se ejecuta en los puntos 1 y 2 solamente. -> Si un proceso entra en un lazo cerrado , el SO no responde. (DOS).

SO exporpiativo(preemptive): Es en el que el planificador se ejecuta en cualquiera de los puntos 1,2,3 ó 4), y se programa un timer externo al procesador para que realice una interrupción cada cierto período.

Un SO preemptive (UNIX, WinNT, etc). debe proporcionar mecanismos de sincronización a los procesos, ya que estos pueden ser interrumpidos en cualquier momento. (Ejemplo: memoria compartida).

Syscall: Preemptive?: en la mayoría de UNIX no: Se deshabilita el manejo de interrupciones mientras se maneja la syscall. En Linux, desde Linux 2.6 es kernel es preemptive.

- Ventajas: Realtime: tiempo de respuesta.

- Desventajas: Complejidad.

Niveles de planificación

Planificación a largo plazo (planificador de trabajos): es el encargado de crear los procesos y decide cual es el próximo trabajo que se va a ejecutar. Sólo existe en los sistemas de procesamiento por lotes. En los de tiempo compartido su misión es cargar los programas en memoria.

Planificación a medio plazo (planificador de procesos inactivos o swapping): decide si un proceso que está suspendido o bloqueado debe ser extraído temporalmente de la memoria, para reducir el grado de multiprogramación. Sólo existe en los sistema de tiempo compartido.

Planificación a corto plazo (planificador del procesador): tiene la responsabilidad de decidir el cómo y cuando un proceso preparado va a acceder al procesador (funciones de la multiprogramación). Está siempre residiendo en la memoria y se ejecuta con mucha frecuencia

(20 ms) y debe ser de ejecución muy rápida. Es importante que de un buen servicio a los procesos para que el usuario no perciba que está compartiendo el sistema con otros.

Despachador

Una vez que el Planificador seleciona el proceso a correr, pasa el control a despachador. Este se encarga de: ejecutando. (context switch).

- Cambiar de Contexto (context switch).

- Cambiar de Kernel a User mode.

- Saltar a la dirección donde el proceso se estaba

Criterios de planificación

- Utilización del Procesador: Porcentaje de tiempo en que el procesador esta ocupado.

- Rendimiento (Throughput): Número de procesos ejecutados por unidad de tiempo.

- Tiempo de Servicio(T): Tiempo tomado para procesar una petición (un proceso, un programa). excluyendo el tiempo gastado en la lista de procesos ‘esperando’.

- Tiempo de Ejecución(t): Tiempo de servicio menos tiempo de espera.

- Tiempo de Espera (E): Tiempo que un proceso esta en la lista de procesos ‘esperando’.

- Tiempo de Respuesta: Velocidad con la que el ordenador da respuesta a una petición. (depende de los dispositivos de E/S).

- Latencia. Básicamente, mide el tiempo transcurrido entre la realización de una petición y el comienzo de la visualización o ejecución de los resultados. Se mide en unidades de tiempo (segundos, milisegundos...)

Objetivos de la planificación

Justicia, sin favorecer, ni perjudicar a ninguno de los procesos.

Máxima capacidad de ejecución, disminuyendo el número de cambios entre procesos.

Máximo número de usuarios interactivos.

Predictibilidad, intentando conocer de antemano como será la ejecución de un proceso.

Minimización de la sobrecarga, ya que a menor sobrecarga se consigue mayor velocidad de procesamiento (los cambios de contexto deben minimizarse).

Equilibrio en el uso de recursos, procurando que sean usados equitativamente el mayor tiempo posible.

Seguridad de las prioridades, a mayor prioridad ejecución más rápida.

Algoritmos de planificación

Primero en llegar, primero en ser atendido:

FCFS (FIRST COME, FIRST SERVED):

Se procesan hasta terminar, el resto de procesos en cola esperando, sencillo pero de pobre ejecución, hacen esperar mucho a los tiempos cortos, es no expropiativa.

El Proceso más corto primero (No expropiativo):

SJF (Short Job First):

En este caso es necesario PREDECIR los tiempos que demora el proceso en ejecutarse. Esto se puede hacer suponiendo los ciclos anteriores.

Cuando llega un proceso nuevo su tiempo total se compara con el tiempo que falta para que el proceso termine de ejecutarse, si es menor se cede el procesador al nuevo proceso.

El tiempo mas corto restante (Expropiativo):

SRT (Short Remaing Time):

Cuando un proceso nuevo llega, su tiempo total de ejecución es comparado y si este es menor que el proceso que se esta ejecutando el viejo proceso se detiene para dar paso al nuevo, hay que predecir el tiempo de los procesos una vez mas, si se calcula mal el tiempo, el SO aborta el proceso.

Asignación cíclica:

RR (Round Robin) q=1

Se concede a cada proceso un periodo de tiempo de ejecución fijo, q (quantum), si se supera el proceso es pasado a la cola de espera y es atendido por mecanismo FIFO o por prioridades, si los valores de q son muy altos se convierte en FCFS, si el valor tiende a 0 sobrecarga el sistema, en la práctica 10<q<100ms, si un proceso es creado cuando acaba el q del otro se supone que el anterior llego primero.

Asignación cíclica:

RR (Round Robin) q=3

Incrementando q el tiempo de servicio se mantiene cte. y el tiempo de espera crece en función de ejecución.

Baja sobrecarga sin los Procesos están en memoria.

Es la política más utilizada en tiempos de espera compartidos.

Es un método bastante justo y no ex-propiativo.

El tamaño de q depende de:

el tipo de sistema

el nº de procesos

Prioridades:

Se asigna al procesador el proceso con mayor prioridad.

Las prioridades pueden ser asignadas interna o externamente.

El problema principal en estos casos son los procesos con baja prioridad

Puede ser expropiativo o noexpropiativo.

Colas Multiples

Multilevel Queue (MQ):

Es posible conseguir mayor flexibilidad en la planificación de los Procesos si creamos varias colas y cada una con distinta planificación.

Los Procesos se asignan a una u otra dependiendo de sus necesidades y tipo.

Para conocer que cola suministrará el Proceso al procesador se utiliza un algoritmo no-expropiativo de prioridad fija.

Colas Multiples

Multilevel Queue (MQ):

Colas Multiples con retroalimentación

Multilevel Queue Feedback (MQF):

Como es difícil determinar el trato justo que ha de recibir cada proceso a priori, se opta por favorecer a:

Los procesos cortos

Los procesos limitados por E/S

Este método divide a los procesos en varias colas de manera que la numeración más baja corresponde a una mayor prioridad.

Cuando el proceso consume su quantum, entra el primero de la cola de mayor prioridad (nivel más bajo).

Una vez que un proceso haya consumido un tiempo determinado en una cola, será colocado al final de la cola inmediatamente inferior en prioridad.

Es expropiativa y adaptable (gestión de colas con RR y FCFS)

Colas Multiples con retroalimentación

Multilevel Queue Feedback (MQF):

Planificación para Multiprocesamiento

Este tema esta dado por la capacidad de paralelismo de los procesadores.

Se puede hacer una división clara del paralelismo dado por el nivel de sincronización que se puede tener entre los procesos permitiendo esto tener un nivel de granularidad distinto sobre los procesos que pueden ser ejecutados:

Grano Fino paralelismo: Paralelismo definido en una sola instancia, no necesariamente involucra al SO, no hay una alta tasa de sincronización.

Grano medio: Paralelismo potencial de una aplicación puede ser implementada por múltiples hilos en un solo proceso, el nivel de coordinación a veces es dado por un programador.

Grano Grueso: Multiprocesamiento concurrente de procesos de un ambiente de ultiprogramación

Grano muy grueso: La sincronización es distribuida en una red distribuida.

Paralelismo independiente: Múltiples procesos no relacionados.

Asignación de Procesos al Procesador

Asignación Master/slave: Las funciones del Kernel siempre corren sobre un procesador. Otro procesador ejecuta procesos de usuarios.

- Ventaja: Los conflictos de recursos se ven simplificados a un solo procesador.

- Desventaja: Falla del procesador Master?, el procesador principal hace la asignación==> cuello de botella.

Por asignación: SO se puede ejecutar sobre cualquier procesador.

Cada procesador aplica sus propios algoritmos para los procesos. Es similar a como funciona SOLARIS Y (SMP).

Despacho de procesos

Después de la asignación, el despachador debe decidir de la cola de procesos en espera que proceso debe ser despachado.

Estrategias de multiprogramación basados en un solo procesador (contador productivo) pueden ser establecidas acá.

Prioridades e histórico de procesos no es suficiente.

Una cola simple de procesos o una cola de multiprioridades pueden ser usadas.

Modelos de colas multiservidores: Múltiples cola vs una sola cola, el análisis de desempeño de los procesos siendo asignados a distintas colas dado el número de procesos puede no ser la mejor opción.

Conclusión: La recomendación puede ser usar FCFS sobre uno de los procesadores combinado con el uso de una cola de prioridades y que sobre el otro procesador se atiendan el resto de procesos.

Planificación de hilos

Si una aplicación es implementada para que funciones con un conjunto de hilos y que compartan por supuesto una dirección única de memoria por proceso, se puede seguir alguno de estos métodos:

Balanceo de cargas: Sabemos que si un proceso esta formado por distintos hilos un buen método es permitir que la planificación del SO sea la que se encargue de decidir cuales hilos van a que procesador, desventaja, como puede un hilo repetir el mismo procesador (cache), muchos procesadores buscando procesos con una única dirección de memoria pueden presentarse para este método.

Planificación por grupos: Grupos de hilos se ejecutan juntos, si son procesos íntimamente relacionados los tiempos se reducen considerablemente. Desventajas son dadas por la consideración de operar todos los hilos como un

todo deja algunos procesadores ociosos si no se usa un buen algoritmo de planificación.

Asignación de procesadores dedicados: Consiste en dedicar procesadores durante toda la duración de la ejecución de la aplicación, este método es bueno si: hay muchos procesadores, si se puede controlar el número de hilos por aplicativo.

Planificación dinámica: Dependerá de si el lenguaje que programa el aplicativo o el SO permiten controlar dinámicamente el número de procesos sobre el procesador, un método es examinar si algún procesador esta ocioso de ser así asignarles grupos de hilos.

Planificación en tiempo real

La computación en tiempo real se puede definir como aquella en la que la corrección del sistema depende no solo del resultado lógico de la computación sino también del momento en el que se producen resultados.

Un sistema en tiempo real duro: Tiene un tiempo para la ejecución de las tareas.

Un sistema en tiempo real suave: Tiene un tiempo límite deseable pero no obligatorio.

Características de sistemas operativos en tiempo real

- Determinismo.

- Reactividad

- Control de usuario

- Fiabilidad

- Operación de fallo suave

Determinismo

Un SO es determinista en el sentido de ejecutar operaciones en instantes de tiempos fijos predeterminados o dentro de intervalos de tiempos predeterminados, es difícil que en un sistema operativo sea determinista, para SO en tiempo real el determinismo esta dado por eventos externos y temporizaciones. El determinismo esta dado en los tiempos en que atiende las interrupciones y si puede atender todos los requerimientos. En SO no-RT esta demora puede estar en el orden de 10’s y 100’s de milisegundos, en SO RT esta dado en pocos microsegundos hasta 1 milisegundo.

Reactividad

Depende de cuanto tarda el SO después que reconoce la interrupción, se incluyen algunos aspectos como:

-Tiempo para manejar la interrupción y comenzar a ejecutar la rutina de servicio de interrupción.

- La cantidad de tiempo necesario para la ejecución de la interrupción.

- El tiempo cuando hay mas de una interrupción por ejecutarse.

Control de usuario

El usuario tiene control sobre:

- Prioridades.

- Paginación o swapping.

- Algoritmos de transferencias de disco.

- Tiempo real de tipo suave o duro.

- Etc.

Fiabilidad

En SO no RT el fallo de los procesadores, no cumplimiento de las tareas, etc, es mas sencillo de ser solventado que en SO RT, en estos están de por medio tareas como datos financieros, manejo de equipos en hospitales, etc.

Operación de fallo suave

Capacidad de fallar de forma tal que se preserven tantos datos como sea posible.

Requerimientos de tiempo real

- Rápido cambio de contexto.

- Capacidad de almacenamiento rápido.

- Planificación no-expropiativa.

- Respuesta rápida a interrupciones.

La meta es completar la mayor cantidad de tareas en el menor tiempo posible.

Algoritmos para tiempo real

Es necesario saber que existen dos tipos de eventos:

- Periódicos: Su tiempo de ocurrencia no es frecuente, ni predecible, ej: un loop.

- Aperiódicos: Su tiempo de ocurrencia es frecuente e impredecible, ej: un click del mouse.

Los enfoques se dividen a varias clases de algoritmos.

- Enfoque estático dirigido por tablas.

- Enfoque estático expropiativo dirigido por prioridad.

- Enfoque dinámico basado en un plan.

- Enfoque dinámico de mejor esfuerzo.

Clases de algoritmos

- Enfoque estático dirigido por tablas: Aplicable a tareas periódicas, se necesitan datos como tiempo periódico de llegada, tiempo de ejecución, plazo periódico de ejecución y prioridad de las tareas. Se debe definir un plan que nos diga cuando ejecutar cada tarea.

- Enfoque estático expropiativo dirigido por prioridad: Debe usar un método expropiativo basado en prioridades (no RT), para la planificación se debe basar en que demora mas las tareas.

- Enfoque dinámico basado en un plan: Se determina un plan, que incluye a las tareas ya planificadas más cualquier nueva tarea que no entorpezca el tiempo.

- Enfoque dinámico de mejor esfuerzo: Cuando llega un nuevo proceso se le asigna una prioridad basado en las características del proceso. En este caso los procesos no se ejecutan de forma periódica.

Planificación por plazos

La mayoría de los sistemas operativos actuales en tiempo real se diseñaron con el objetivo de dar inicio a las tareas de tiempo real tan rápidamente como fuera posible, y por lo tanto, hacen hincapié en una rápida gestión de las interrupciones y expediciones de las tareas. De hecho, no hay medidas particularmente útiles en la evaluación de los sistemas operativos en tiempo real. En las aplicaciones en tiempo real generalmente no preocupa la velocidad absoluta, sino completar las tareas en el momento mas apropiado, ni antes ni después, a pesar de las peticiones

dinámicas de recursos y los conflictos, la sobrecarga de proceso y los fallos de hardware o software.

Planificación en GNU/Linux

Linux está basado en la planificación tradicional de Unix  añadiendo 2 clases de prioridad para procesos de tiempo real flexibles. Las tres clases de prioridad de Linux son las siguientes: ð    SCHED_FIFO: FIFO o FCFS, no se obliga a dejar el procesador, se usa en procesos de tiempo real. ð   SCHED_RR: Usan su quantum de tiempo, se obliga al proceso a dejar el procesador. ð   SCHED_OTHER: hilos que no son de tiempo real y otros.

Planificación en GNU/Linux

Dentro de cada clase se utilizan múltiples prioridades, siendo las prioridades de las clases de tiempo real mayores que el resto. Para los hilos FIFO, se aplican las siguientes reglas:

1.      El sistema no interrumpe la ejecución de un hilo FIFO, excepto en los siguientes casos:

a)   Pasa a estar listo otro hilo FIFO de mayor prioridad.

b)   El hilo FIFO en ejecución  se bloquea a la espera de un evento, como una E/S.

c)   El hilo FIFO en ejecución abandona el procesador como resultado de la ejecución de la primitiva sched_yield.  

2. Cuando se interrumpe un hilo FIFO en ejecución, pasa a la cola asociada a su prioridad.

3. Cuando un hilo FIFO pasa a listo y tiene mayor prioridad que el hijo que está en ejecución, se expulsa al hilo en ejecución y pasa a ejecutar el hilo de mayor prioridad. Si más de un hilo tiene esta mayor prioridad, se escoge al que lleva más tiempo esperado.

La política SCHED_RR se comporta de forma similar a la SCHED_FIFO, excepto por el uso de un cuanto de tiempo asociada a cada hilo. Cuando un hilo SCHED_RR ha consumido su cuanto de tiempo, pasa a suspendido y se escoge un hilo de tiempo real con una prioridad igual o mayor.

Esta ejecución de la figura es dada por las prioridades de los distintos hilos.

La planificación descrita anteriormente funciona para el kernel 2.4, para el kernel 2.6 se decido tomar lo mejor del kernel 2.4 y usar algunas nuevas características, para tratar de mejorar el desempeño de los procesos.

- Tienen mayor prioridad a los que les quede mayor tiempo en el procesador

- Se aumenta ligeramente la prioridad de los hilos del mismo proceso.

- Se añade la prioridad “nice” colocada por el usuario.

- Los procesos se ejecutan en un solo procesador a menos que haya un bloqueo de otro procesador.

- Ejecutar los hijos antes que sus padres, lo cual mejora el desempeño.

Planificación Windows

Las prioridades en Windows se organizan de dos formas: tiempo real y variable. Cada una de estas bandas consta de 16  niveles de prioridad. Los hilos que requieren atención inmediata están en clase de tiempo real, que incluye funciones como comunicaciones tareas de tiempo real. En general, puesto que Windows utiliza un planificador expropiativo con prioridades, los hilos con prioridades de tiempo real tienen preferencia sobre los otros hilos. En un monoprocesador, cuando un hilo cuya prioridad es mayor que la del que se ejecuta en ese momento pasa a estar Listo, el hilo de menor prioridad es expulsado y se asigna el procesador al de mayor prioridad.

Las prioridades se gestionan de forma algo diferente en las clases. En la clase de prioridad de tiempo real, todos los procesos tienen una prioridad fija que no cambia nunca.

Planificación Unix

Dentro de la clase de tiempo compartido, un proceso tiene prioridad variable. El planificador reduce su prioridad cada vez que agota un cuanto de tiempo, y le

incrementa cuando se bloquea un evento o recurso. El cuanto de tiempo asignada a un proceso de tiempo compartido depende de su prioridad, oscilando entre 10ms para prioridad 0 y 100ms para prioridad 59. Cada proceso de tiempo real tiene una prioridad fija de un cuanto de tiempo fijo. de Dentro de la clase de tiempo.

3.2 MANEJO DE MEMORIA SECUNDARIA

A diferencia de la Memoria Principal la Memoria Secundaria, auxiliar, masiva, externa no es tan veloz pero tiene gran capacidad para almacenar información en dispositivos tales como discos, cintas magnéticas, discos ópticos. Frecuentemente los datos y programas se graban en la Memoria Secundaria, de esta forma, cuando se ejecuta varias veces un programa o se utilicen repetidamente unos datos, no es necesario darlos de nuevo a través del dispositivo de entrada

En la Memoria Secundaria un archivo consta de un conjunto de bloques (correspondiente a la cantidad de información que se transfiere físicamente en cada operación de acceso (lectura o escritura).

El Sistema Operativo o Sistema de Gestión de Archivos es el encargado de la asignación de bloques a archivos, de lo que surgen dos cuestiones, en primer

lugar, debe asignarle el espacio de Memoria Secundaria a los archivos y, en segundo lugar, es necesario guardar constancia del espacio disponible para asignar.

El sistema de archivos se ocupa primordialmente de administrar el espacio de almacenamiento secundario, sobre todo el espacio en disco. El manejo del espacio libre en disco se lleva a cabo de la siguiente manera:

· Vector de bits

· Lista ligada (lista libre)

· Por conteo (agrupación)

Vector de bits. El espacio libre en disco es frecuentemente implementado como un mapa de bits, donde cada block es representado por un bit y si el bloc es libre el bit es cero de lo contrario está asignado.11000111

Lista ligada. Una lista ligada de todos los blocks libres. Otra implantación se consigue guardando la dirección del primer block libre y el número de los blocks libres contiguos que le siguen. Cada entrada de la lista de espacio libre consiste de una dirección de disco y un contador (por conteo).

Lista de espacio libre enlazada en el disco

Por agrupación. Se almacena la dirección en n blocks libres en el primer block libre y el último contiene la dirección de otro block que contiene la dirección de otros blocks libres.

Para manejar los espacios en disco existen los siguientes métodos:

Contiguos Ligados Indexados

Contiguos. Esta asignación requiere que cada archivo ocupe un conjunto de direcciones contiguas en el disco, su asignación es definida por la dirección del primer bloc y la longitud del archivo.

Cuando se crea un archivo se le asigna un único conjunto contiguo de bloques, esta es una estrategia de asignación previa que emplea secciones de tamaño variable. La tabla de asignación de archivos necesita solo una entrada por cada archivo y que muestre el bloque de comienzo y la longitud del archivo. La asignación contigua es la mejor para un archivo secuencial.

La asignación contigua presenta algunos problemas, como la fragmentación externa. Lo que hace difícil encontrar bloques contiguos de espacio de tamaño suficiente., lo que lleva a ejecutar un algoritmo de compactación para libera el espacio adicional en el disco.

Asignación ligada o encadenada. Cada archivo es una lista ligada de blocks y el directorio contiene un apuntador al primer bloc y al último.

La asignación se hace con bloques individuales, cada bloque contendrá un puntero al siguiente bloque de la cadena. La tabla de asignación de archivos necesita una sola entrada por cada archivo que muestre el bloque de comienzo y la longitud del mismo, cualquier bloque puede añadirse a la cadena. No hay que preocuparse por la fragmentación externa porque solo se necesita un bloque cada vez.

Una consecuencia del encadenamiento es que no hay cabida para el principio de cercanía, si es necesario traer varios bloques de un archivo al mismo tiempo, se necesita una serie de accesos a partes diferentes del disco por lo que se debe ejecutar un algoritmo de compactación para liberar el espacio adicional en el disco.

Asignación Indexada. Cada archivo tiene su propio bloc de índice el cual es un arreglo de direcciones de bloc.

En esta asignación la tabla de asignación de archivos contiene un índice separado de un nivel para cada archivo: el índice posee una entrada para cada sección asignada al archivo. Normalmente, los índices no están almacenados físicamente como parte de la tabla de asignación de archivos. Mas exactamente el índice de

archivo se guardara en un bloque aparte y la entrada del archivo en la entrada de asignación apuntara a dicho bloque.

La asignación puede hacerse por bloques de tamaño fijo, O en secciones de tamaño variable. La asignación por bloques elimina la fragmentación externa, mientras que la asignación por secciones de tamaño variable mejora la cercanía. En cualquier caso, los archivos pueden concentrarse en zonas cercanas de cuando en cuando. La concentración reduce el tamaño del índice en el caso de secciones de tamaño variable, pero no en el caso de asignación por bloques.

La asignación indexada soporta tanto el acceso secuencial como el acceso directo a los archivos y por ello se ha convertido en la forma más popular de asignación de archivos.

En un sistema de cómputo, los elementos que se declaran para almacenamiento son los Fyle System. Cuándo existe una solicitud de almacenamiento o manejo de bloc libres en un file system surge una interrogante ¿cómo atenderlas? esto se lleva a cabo mediante una planificación de discos y para esto existen las siguientes políticas de planificación. 

a) FCFS

b) SSTF

c) SCAN

d) SCAN de n-pasos

e) C-SCAN

f) Esquema Eschenbach

BIBLIOGRAFIA

http://es.scribd.com/doc/38727616/Estructura-de-Un-S-O-Reporte http://www.mitecnologico.com/Main/ManejoEspacioMemoriaSecundaria http://html.rincondelvago.com/memoria-secundaria.html http://ditec.um.es/deiso/apuntes/tema2.pdf http://www.monografias.com/trabajos11/oper/oper.shtml#es http://pitagoras.usach.cl/~eflores/lcc/cd_arq/arquitectura/material/administracion-

procesador.pdf