.7 ESTRUCTURA DEL SISTEMA OEPRATIVO 1.7.1 Sistemas monoliticos Su estructura consiste en que no tiene estructura. El SO se describe como una coleccion de procedimientos, cada uno puede llamar a cualquiera de los otros cuando lo necesite. El programa objeto del SO se construye compilando primero todos los procedimientos individuales, para luego enlazarlos todos en un unico fichero objeto, utilizando el enlazador del sistema. Cualquier proceso puede ver a cualquier otro. Los servicios proporcionados por el SO se solicitan colocando parámetro en un lugar bien definido (pila) y ejecutando después una instrucción TRAP. Entonces, el SO obtiene estos parametro y determina que llamada al sistema debe ejecutarse. Despues de eso, utiliza el numero de llamada al sistema k como un indice para una tabla que contiene en su entrada k un puntero al procedimiento que lleva a cabo esa llamada. Sistemas de capas Organizar el SO en una jerarquía de capas, cada una cimentada en la que está abajo. La capa 0 se ocupaba de la asignación del procesador conmutando entre procesos al presentarse interrupciones o expirar temporizadores. Esta capa hacía posible la multiprogramación básica de los CPU. La capa 1 se encargaba de la administración de memoria, el software de la capa 1 se encargaba de que las páginas se transfirieran a la memoria si se las necesitaba. La capa 2 manejaba la comunicación entre cada proceso y la consola del operador. La capa 3 se encargaba de administrar los dispositivos de E/S yde colocar en búferes los flujos de información hacia y desde ellos. En la capa 4 estaban los programas de usuario. En proceso del operador del sistema de ubicaba en la capa 5. 1.7.3 MAQUINAS VIRTUALES . VM/370 se basaba en: Un sistema de tiempo compartido proporciona: (1)
multiprogramación y (2) una máquina extendida con una interfaz más conveniente que el hardware desnudo. La esencia del VM/370 consiste en separar por completo estas dos funciones. .El corazón del sistema, conocido como MONITOR DE MAQUINA VIRTUAL, se ejecuta sobre el hardware desnudo y realiza la multiprogramación, proporcionando varias maquinas virtuales a la siguiente capa. . Las maquinas virtuales son COPIAS EXACTAS del hardware desnudo que incluye todo lo que tiene la maquina real. . Diferentes maquinas virutales pueden ejecutar SO distintos . El concepto de máquina virtual se utiliza mucho hoy en día en un contexto diferente: - Al diseñar el Pentium y su software, tanto Intel como Microsoft se percataron de que podría haber una gran demanda de gente queriendo ejecutar su software antiguo sobre el nuevo hardware. Por ese motivo, Intel incluyó un modo 8086 virtual en el Pentium. De este modo, la máquina actúa como un 8086 (que es idéntico a un 8088 desde el punto de vista del software), incluyendo el direccionamiento de 16 bits con un límite de 1 MB. . Otro área donde se utilizan las máquinas virtuales es en la ejecución de programas en Java con la JVM (Java Virtual Machine) . El compilador de Java produce código para la JVM
Subsistema de gestión de procesos Procesos Definición de procesos
Un proceso es básicamente un programa en ejecución. Cada proceso tiene asociado un espacio de direcciones: una lista de posiciones de memoria desde algún mínimo (normalmente 0) hasta algún máximo. Creación de un proceso Hay cuatro sucesos principales que causan la creación de un proceso: 1. Inicialización del sistema Cuando se arranca un SO, se crean varios procesos. Algunos son de primer
plano; es decir, procesos que interactúan con usuarios (humanos) y trabajan paraellos. Otros son procesos de segundo plano que no están asociados con un usuario en particular, sino que tienen una función específica. Los procesos que quedan en segundo plano para encargarse de alguna actividad. Estos procesos se llaman demonios (daemons). 2. Ejecución de una llamada al sistema para crear procesos por parte de un proceso en ejecución Los procesos en ejecución emiten llamadas al sistema para crear uno o más procesos que le ayuden en su labor. La creación de procesos tiene especial utilidad cuando el trabajo a realizar puede formularse con facilidad a partir de varios procesos relacionados, pero independientes, que interactúan entre sí. 3. Solicitud de un usuario para crear un proceso En los sistemas interactivos, los usuarios pueden iniciar un programa tecleando un comando o haciendo (doble) clic en un icono. Ambas acciones inician un proceso nuevo y ejecutan allí el programa seleccionado. 4. Inicio de un trabajo por lotes Esta sólo es válida en los sistemas por lotes de los mainframes grandes. En ellos, los usuarios pueden enviar trabajos por lotes al sistema. Cuando el sistema operativo decide que tienen los recursos suficientes para ejecutar otro trabajo, crea un proceso y ejecuta en él el siguiente trabajo de la cola de entrada. En todos estos casos un proceso se crea haciendo que un proceso existente ejecute una llamada al sistema para crear procesos. En UNIX sólo hay una llamada al sistema para crear un proceso: fork. Está crea una copia exacta del proceso invocador. Después de fork, los dos procesos, el padre y elhijo, tiene la misma información. En Windows una sola llamada de Win32, CreateProcess, se encarga tanto de crear procesos como de cargar el programa correcto en el proceso nuevo. Tanto en UNIX como en Windows, una vez que se crea un proceso, tanto el padre como el hijo tienen sus propios espacios de direcciones distintos. Terminación de procesos Los procesos pueden terminar por alguno de los siguientes motivos:
1. Terminación normal (voluntaria) La mayoría de los procesos termina porque ya realizó su trabajo. Ejecuta una llamada para indicar al sistema operativo que ya terminó. Esta llamada es un exit en UNIX y ExitProcess en Windows. 2. Terminación por error (voluntaria) Es cuando el proceso descubre un error fatal. 3. Error fatal (involuntaria) Es cuando un error causado por el proceso, a menudo debido a un defecto del programa. 4. Terminación por otro proceso (involuntaria) Es cuando otro proceso ejecute una llamada para pedir al SO que termine el proceso en cuestión. En UNIX la llamada es kill. La función correspondiente en Win32 es TerminateProcess. En ambos casos, el proceso que ejecuta la llamada debe contar con la debida autorización. En algunos sistemas, cuando un proceso termina, sea en forma voluntaria o no, todos los procesos que creó también finalizan de inmediato. Sin embargo, ni UNIX ni Windows funcionan así.
Jerarquía de procesos Cuando un proceso crea otro, el proceso padre y el hijo mantienen cierta asociación. El proceso hijo puede crear más procesos y formar así una jerarquía de procesos. En UNIX, unproceso, todos sus hijos y sus demás descendientes forman un grupo de procesos. De manera individual, cada proceso puede atrapar la señal, ignorarla o realizar la acción predeterminada, que es finalizar a causa de la señal. Un proceso especial, llamado init, está presente en la imagen de arranque. Todos los procesos del sistema pertenecen a un solo árbol que tiene init como raíz. Windows no tiene el concepto de jerarquía de procesos. Todos los procesos son iguales. Lo único que podría parecerse a una jerarquía de procesos es cuando se crea un proceso: el padre recibe una “ficha” especial (llamada [identificador]) que
le sirve para controlar al hijo. Sin embargo, el padre está en libertad de transferir la
ficha a algún otro proceso, deshaciendo así la jerarquía. En UNIX, los procesos no pueden desheredar a sus hijos. Estados de un proceso Un proceso puede tener tres estados: 1. En ejecución (en realidad, usando la CPU en ese instante) 2. Listo (puede ejecutarse; detenido en forma temporal para permitir que se ejecute otro proceso). 3. Bloqueado (no puede ejecutarse mientras no ocurre cierto suceso externo). Puede haber cuatro transiciones entre estos tres estados. 1. La primera, se presenta cuando un proceso descubre que no puede continuar. Block o Pause para pasar al estado bloqueado. 2. Es consecuencia de las acciones del calendarizador o despachador de procesos que formar parte del SO. Ocurre cuando el calendarizador decide que el proceso que se esta ejecutando ya lo hizo durante suficiente tiempo, y es momento de conceder a otro procesoel tiempo de CPU. 3. Es consecuencia de las acciones del calendarizador o despachador de procesos que formar parte del SO. Ocurre cuando los demás procesos han recibido su porción equitativa y toca el primero recibir la CPU para ejecutarse otra vez. 4. Se presenta cuando ocurre el suceso externo que un proceso estaba esperando. Si ningún otro proceso está ejecutándose en ese instante, se activará la transición 3 y el proceso comenzará a ejecutarse. De lo contrario, tendrá que esperar un momento en el estado listo hasta que la CPU esté disponible y le toque su turno. Implementación de los procesos Para implementar el modelo de procesos, el SO mantiene una tabla llamada tabla de procesos, con una entrada por proceso. Esta entrada contiene información que debe guardarse cuando el proceso pasa del estado en ejecución al listo o bloqueado, para que se le pueda volver a poner en marcha posteriormente, como si nunca se hubiera detenido. Cada clase de dispositivos de E/S está asociada con una posición de memoria llamada vector de interrupción. Lo primero que hacen todos los procesos de servicio de interrupción es guardar
los registros, a menudo en la entrada correspondiente al proceso actual de la tabla de procesos. Luego, se saca la información que la interrupción metió en la pila, y el apuntador de pila se ajusta de modo que apunte a una pila temporal empleada por el manejador de procesos. Una vez que dicho procedimiento ha terminado su labor, con lo cual es probable que ahora un proceso esté listo, se llama al calendarizador para ver quién seejecutará a continuación. Hay dos formas principales de implementar subprocesos: en espacio de usuario y en el kernel. El primer método consiste en colocar por completo el sistema de subprocesos en espacio de usuario. El kernel no sabe nada de ellos. La primer ventaja es que puede implementarse un sistema de subprocesos en el nivel de usuario en un sistema operativo que no maneje subprocesos. Cuando los subprocesos se administran en espacio de usuario, cada proceso necesita su propia tabla de subprocesos privada para dar seguimiento a sus subprocesos. La tabla de subprocesos es administrada por el sistema de tiempo de ejecución. Los subprocesos en el nivelde usuario tienen otras ventajas, como permitir que cada proceso tenga su propio algoritmo de calendarización personalizado. A pesar de su buen desempeño, los sistemas de subprocesos en el nivel de usuario tienen problemas importantes. El principal es la forma en que se implementan las llamadas bloqueadoras al sistema. Algunas versiones de UNIX cuentan con una llamada al sistema, select, que indica al invocador si una llamada read propuesta se bloqueará o no. Algunos argumentos en contra del uso de los sistemas de subprocesos en el nivel de usuario es que se producen fallos de página, además si un subproceso comienza a ejecutarse, ningún otro subproceso de ese proceso se ejecutará si el primero no cede de manera voluntaria la CPU. Por otro lado los programadores quieren subprocesos precisamente en las aplicaciones en las que éstos se bloquean a menudo, como es un servidor Web de múltiples subprocesos. Implementación de hilos en el kernel Algunas características de los subprocesos en el kernel es que no se necesita un sistema de tiempo de ejecución en cada uno, no hay una tabla de subprocesos en cada proceso. El kernel tiene una tabla que lleva el control de todos los
subprocesos del sistema. La información de cada subproceso es la misma que se usa con subprocesos en el nivel de usuario, pero ahora están en el kernel, no en el espacio de usuario. Todas las llamadas que podrían bloquear un subproceso se implementan como llamadas al sistema y tienen un costo mucho mayor que las llamadas a procedimientos de un sistema de tiempo de ejecución.Debido al costo relativamente mayor de crear y destruir subprocesos en el kernel, algunos sistema reciclan sus subprocesos. Los subprocesos de kernel no necesitan nuevas llamadas al sistema no bloqueadoras. Implementaciones híbridas Se trata de combinar las ventajas de los subprocesos en el nivel de usuario y en el nivel de kernel. Una de ellas es usar subprocesos en el nivel de kernel y luego multiplexar subprocesos en el nivel de usuario. El kernel sólo tiene conocimiento de los subprocesos en el nivel de kernel y únicamente los calendariza a ellos. Algunos de ellos podrían tener multiplexados múltiples subprocesos de nivel de usuario. Éstos se crean, destruyen y calendarizan igual que los de nivel de usuario en un proceso que se ejecuta en un sistema operativo sin capacidad de múltiples subprocesos. En este modelo, cada subproceso en el nivel de kernel tiene algún conjunto de subprocesos en el nivel de usuario que se turnan para usarlo. omunicación entre procesos Los procesos necesitan comunicarse con otros procesos. Para ello hay que cuidar tres aspectos: 1. Cómo puede un proceso pasar información a otro. 2. Asegurarse de que dos o más procesos no se estorben al realizar actividades cruciales. 3. Un correcto ordenamiento cuando existen dependencias. Dos de estos aspectos también se aplican a subprocesos. 1. La transferencia de información.
2. Evitar estorbarse y el ordenamiento correcto son idénticos en el caso de los subprocesos: se presentan los mismos problemas y se pueden usar las mismas soluciones. Condiciones de carreraEn algunos sistemas operativos, procesos que están colaborando podrían compartir un área de almacenamiento que ambos pueden leer y escribir. El almacenamiento compartido podría estar en la memoria principal, o bien, ser un archivo compartido; la ubicación de la memoria compartida no altera la naturaleza de la comunicación ni los problemas que se presentan. Situaciones en la que dos o más procesos están leyendo o escribiendo datos compartidos y el resultado final depende de quién se ejecuta y precisamente cuándo, se denominan condiciones de competencia. Relaciones críticas Debemos evitar las condiciones de competencia, para ello se necesita exclusión mutua, alguna forma de asegurarnos de que si un proceso está utilizando una variable compartida o un archivo compartido, los demás procesos no podrán hacer lo mismo. La parte del programa en la que se tiene acceso a la memoria compartida se denomina región crítica o sección crítica. Existen cuatro condiciones para tener una buena solución y así evitar las condiciones de competencia: 1. Dos procesos no pueden estar al mismo tiempo dentro de sus regiones críticas. 2. No pueden hacerse suposiciones sobre las velocidades ni el número de las CPUs. 3. Ningún proceso que se esté ejecutando afuera de su region crítica puede bloquear a otros procesos. 4. Ningún proceso deberá tener que esperar de manera indefinida para entrar en su región crítica. Exclusión mutua con espera ocupada Deshabilitar Interrupciones Consiste en hacer que cada proceso inhabilite todas las interrupciones inmediatamente después deingresar en su región crítica y las vuelva a habilitar justo antes de salir de ella. Este enfoque no es recomendable ya que no es prudente conferir a un proceso de usuario la capacidad de inhabilitar todas las interrupciones.
