Guía de Lectura

Procesos de Sistemas Operativos – Control de Lectura.
UNIVERSIDAD GERARDO BARRIOS CENTRO REGIONAL DE USULUTAN FACULTAD DE CIENCIA Y TECNOLOGÍA SISTEMAS OPERATIVOS
DOCENTE: LICDA. CARLA MILAGRO LOPEZ VASQUEZ, MIW.
CONTROL DE LECTURA FECHA DE EVALUACIÓN: 9/ABRIL/2015

Unidad 05 - Procesos de sistemas operativos.

Concepto de proceso.

En un sistema multiprogramado o de tiempo compartido, un proceso es la imagen en memoria de un programa, junto con la información relacionada con el estado de su ejecución. Un programa es una entidad pasiva, una lista de instrucciones; un proceso es una entidad activa, que – empleando al programa– define la actuación que tendrá el sistema. En contraposición con proceso, en un sistema por lotes se habla de tareas. Una tarea requiere mucha menos estructura, típicamente basta con guardar la información relacionada con la contabilidad de los recursos empleados. Una tarea no es interrumpida en el transcurso de su ejecución. Ahora bien, esta distinción no es completamente objetiva -y se pueden encontrar muchos textos que emplean indistintamente una u otra nomenclatura. Si bien el sistema brinda la ilusión de que muchos procesos se están ejecutando al mismo tiempo, la mayor parte de ellos típicamente está esperando para continuar su ejecución- en un momento determinado sólo puede estar ejecutando sus instrucciones un número de procesos igual o menor al número de procesadores que tenga el sistema.

Estados de un proceso.
Un proceso, a lo largo de su vida, alterna entre diferentes estados de ejecución. Éstos son: Nuevo: Se solicitó al sistema operativo la creación de un proceso, y sus recursos y estructuras están siendo creadas. Listo: Está listo para iniciar o continuar su ejecución pero el sistema no le ha asignado un procesador. En ejecución: El proceso está siendo ejecutado en este momento. Sus instrucciones están siendo procesadas en algún procesador. Bloqueado: En espera de algún evento para poder continuar su ejecución (aun si hubiera un procesador disponible, no podría avanzar). Zombie: El proceso ha finalizado su ejecución, pero el sistema operativo debe realizar ciertas operaciones de limpieza para poder eliminarlo de la lista. Terminado: El proceso terminó de ejecutarse; sus estructuras están a la espera de ser limpiadas por el sistema operativo.      
Procesos de Sistemas Operativos – Control de Lectura.

                     
Componentes de los procesos.

La información que debe manipular el sistema operativo relativa a cada uno de los procesos actuales se suele almacenar en una estructura llamada bloque de control de proceso (PCB - Process Control Block). El PCB incluye campos como: Estado del proceso: El estado actual del proceso. Contador de programa: Cuál es la siguiente instrucción a ser ejecutada por el proceso. Registros del CPU: La información específica del estado del CPU mientras el proceso está en ejecución (debe ser respaldada y restaurada cuando se registra un cambio de estado). Información de planificación (scheduling): La prioridad del proceso, la cola en que está agendado, y demás información que puede ayudar al sistema operativo a planificar los procesos. Información de administración de memoria: La información de mapeo de memoria (páginas o segmentos, dependiendo del sistema operativo), incluyendo la pila (stack) de llamadas. Información de contabilidad: Información de la utilización de recursos que ha tenido este proceso —puede incluir el tiempo total empleado y otros (de usuario, cuando el procesador va avanzando sobre las instrucciones del programa propiamente, de sistema cuando el sistema operativo está atendiendo las solicitudes del proceso), uso acumulado de memoria y dispositivos, etcétera. Estado de E/S: Listado de dispositivos y archivos asignados que el proceso tiene abiertos en un momento dado.    

Procesos e Hilos.

La cantidad de información que el sistema operativo debe manejar acerca de cada proceso es bastante significativa. Si cada vez que el planificador elige qué proceso pasar de Listo a En ejecución debe considerar buena parte de dicha información, la simple transferencia de todo esto entre la memoria y el procesador podría llevar a un desperdicio burocrático de recursos. Una respuesta a esta problemática fue la de utilizar los hilos de ejecución, a veces conocidos como procesos ligeros (LWP, Lightweight processes). Cuando se consideran procesos basados en un modelo de hilos, se puede proyectar en sentido inverso que todo proceso es como un solo hilo de ejecución. Un sistema operativo que no ofreciera soporte expreso a los hilos los planificaría exactamente del mismo modo.
Pero visto desde la perspectiva del proceso hay una gran diferencia: si bien el sistema operativo se encarga de que cada proceso tenga una visión de virtual exclusividad sobre la computadora, todos los hilos de un proceso comparten un sólo espacio de direccionamiento en memoria y los archivos y dispositivos abiertos. Cada uno de los hilos se ejecuta de forma (aparentemente) secuencial y maneja su propio contador de programa y pila.

Patrones de trabajo con hilos.
Hay tres patrones en los que caen generalmente los modelos de hilos; se puede emplear más de uno de estos patrones en diferentes áreas de cada aplicación, e incluso se pueden anidar (esto es, se podría tener una línea de ensamblado dentro de la cual uno de los pasos sea un equipo de trabajo):
a) Jefe/Trabajador: Un hilo tiene una tarea distinta de todos los demás: el hilo jefe genera o recopila tareas para realizar, las separa y se las entrega a los hilos trabajadores. Este modelo es el más común para procesos que implementan servidores (es el modelo clásico del servidor Web Apache) y para aplicaciones gráficas (GUI), en que hay una porción del programa (el hilo jefe) esperando a que ocurran eventos externos. El jefe realiza poco trabajo, se limita a invocar a los trabajadores para que hagan el trabajo de verdad; como mucho, puede llevar la contabilidad de los trabajos realizados. Típicamente, los hilos trabajadores realizan su operación, posiblemente notifican al jefe de su trabajo, y finalizan su ejecución.
Patrón de hilos Jefe/Trabajador              
Procesos de Sistemas Operativos – Control de Lectura.
b) Equipo de trabajo: Al iniciar la porción multihilos del proceso, se crean muchos hilos idénticos, que realizarán las mismas tareas sobre diferentes datos. Este modelo es frecuentemente utilizado para cálculos matemáticos (p. ej.: criptografía, render, álgebra lineal). Puede combinarse con un estilo jefe/trabajador para irle dando al usuario una previsualización del resultado de su cálculo, dado que éste se irá ensamblando progresivamente, pedazo por pedazo.
Patrón de hilos Equipo de Trabajo.                  
c) Línea de Ensamblado: Si una tarea larga puede dividirse en pasos sobre bloques de la información total a procesar, cada hilo puede enfocarse a hacer sólo un paso y pasarle los datos a otro hilo conforme vaya terminando. Una de las principales ventajas de este modelo es que ayuda a mantener rutinas simples de comprender, y permite que el procesamiento de datos continúe, incluso si parte del programa está bloqueado esperando E/S. Un punto importante a tener en cuenta en una línea de ensamblado es que, si bien los hilos trabajan de forma secuencial, pueden estar ejecutándose paralelamente sobre bloques consecutivos de información y eventos.
Patrón de hilos Línea de Ensamblado.          

Concurrencia.
 Desde un punto de vista formal, la concurrencia no se refiere a dos o más eventos que ocurren a la vez sino a dos o más eventos cuyo orden es no determinista, esto es, eventos acerca de los cuales no se puede predecir el orden relativo en que ocurrirán. Si bien dos procesos (o también dos hilos) completamente independientes entre sí ejecutándose simultáneamente son concurrentes, los temas que en la presente sección se expondrán se ocupan principalmente de procesos cuya ejecución está vinculada de alguna manera (p. ej.: dos procesos que comparten cierta información o que dependen uno del otro). Aunque una de las tareas principales de los sistemas operativos es dar a cada proceso la ilusión de que se está ejecutando en una computadora dedicada, de modo que el programador no tenga que pensar en la competencia por recursos, a veces un programa requiere interactuar con otros: parte del procesamiento puede depender de datos obtenidos en fuentes externas, y la cooperación con hilos o procesos externos es fundamental. Para presentar la problemática y los conceptos relacionados con la concurrencia suelen utilizarse algunos problemas clásicos, que presentan casos particulares muy simplificados, y puede encontrárseles relación con distintas cuestiones que un programador enfrentará en la vida real. Cada ejemplo presenta uno o más conceptos. Se recomienda comprender bien el ejemplo, el problema y la solución y desmenuzar buscando los casos límite como ejercicio antes de pasar al siguiente caso.

Caso práctico: El Jardín Ornamental.

Planteamiento. Un gran jardín ornamental se abre al público para que todos puedan apreciar sus fantásticas rosas, arbustos y plantas acuáticas. Por supuesto, se cobra una módica suma de dinero a la entrada para lo cual se colocan dos torniquetes, uno en cada una de sus dos entradas. Se desea conocer cuánta gente ha ingresado al jardín así que se instala una computadora conectada a ambos torniquetes: estos envían una señal cuando una persona ingresa al jardín. Se realiza un modelo simplificado de la situación, así que no se estudiarán los detalles del hardware utilizado. Aquí es importante notar que los dos torniquetes son objetos que existen y se comportan en paralelo e independientemente: los eventos que generan no tienen un orden predecible. Es decir, que cuando se escriba el software no se sabe en qué momento llegará cada visitante ni qué torniquete utilizará. Se simulará un experimento en el que 20 visitantes ingresan por cada torniquete. Al final de la simulación deberá haber 40 visitantes contados.
Nota: Elabore un flujograma o algoritmo que represente la solución para el problema “El Jardín Ornamental”. Puede utilizar la estructura que mejor se adapte al caso.  
Procesos de Sistemas Operativos – Control de Lectura.
En un sistema operativo multitarea cuando un proceso agota su porción de tiempo de procesador (quantum) o detiene su ejecución por otra razón, los valores almacenados en registros se preservan (junto con la información sobre el proceso) para poder restaurarlo cuando la ejecución continúe (de esta forma se provee la ilusión de la multitarea en sistemas de un solo núcleo). Así, en el problema del jardín ornamental cada torniquete tiene su propia copia de los valores en los registros. Sin embargo, se supone que el resto de la memoria es compartida (en particular, se utiliza ese hecho para llevar la cuenta de personas que ingresan).

Bloqueos mútuos e inanición.

Bloqueo mútuo: Situación que ocurre cuando dos o más procesos poseen determinados recursos, y cada uno queda detenido, a la espera de alguno de los que tiene el otro. El sistema puede seguir operando normalmente, pero ninguno de los procesos involucrados podrán avanzar.
Inanición: Situación en que un proceso no puede avanzar en su ejecución dado que necesita recursos que están (alternativamente) asignados a otros procesos.

Caso práctico: La cena de los filósofos.

Planteamiento. Cinco filósofos se dan cita para comer arroz en una mesa redonda. En ella, cada uno se sienta frente a un plato. A su derecha, tiene un palito chino, y a su izquierda tiene otro. Los filósofos sólo saben pensar() y comer(). Cada uno de ellos va a pensar() un tiempo arbitrario, hasta que le da hambre. El hambre es mala consejera, por lo que intenta comer(). Los requisitos son:  Sólo un filósofo puede sostener determinado palito a la vez, esto es, los palitos son recursos de acceso exclusivo.
  Debe ser imposible que un filósofo muera de inanición estando a la espera de un palito.
 Debe ser imposible que se presente un bloqueo mutuo.
 Debe ser posible que más de un filósofo pueda comer al mismo tiempo.
Nota: Elabore un flujograma o algoritmo que represente la solución para el problema “La cena de los filósofos”. Puede utilizar la estructura que mejor se adapte al caso.    

 
Ejemplo de Bloqueo Mútuo.
Un bloqueo mutuo puede ejemplificarse con la situación que se presenta cuando cuatro automovilistas llegan al mismo tiempo al cruce de dos avenidas del mismo rango en que no hay un semáforo, cada uno desde otra dirección. Los reglamentos de tránsito señalan que la precedencia la tiene el automovilista que viene más por la derecha. En este caso, cada uno de los cuatro debe ceder el paso al que tiene a la derecha —y ante la ausencia de un criterio humano que rompa el bloqueo, deberían todos mantenerse esperando por siempre. Un bloqueo mutuo se presenta cuando (Condiciones de Coffman):
1. Los procesos reclaman control exclusivo de los recursos que piden (condición de exclusión mutua).
2. Los procesos mantienen los recursos que ya les han sido asignados mientras esperan por recursos adicionales (condición de espera por).
3. Los recursos no pueden ser extraídos de los procesos que los tienen hasta su completa utilización (condición de no apropiatividad).
4. Hay una cadena circular de procesos en la que cada uno mantiene a uno o más recursos que son requeridos por el siguiente proceso de la cadena (condición de espera circular).

 
Servicios POSIX relacionados con el trabajo de procesos.
El término POSIX corresponde a las iniciales de interfase de sistema operativo portable (Portable Operating System Interface). Es un estándar de interfase de sistema operativo, basado en el popular sistema operativo UNIX. El estándar POSIX está actualmente en desarrollo, y su principal objetivo es permitir la portabilidad de aplicaciones a nivel de código fuente, es decir, que sea posible portar una aplicación de un computador a otro sin más que recompilar su código.
El POSIX es un estándar de sistema operativo en evolución. Una importante parte de este estándar está pensada para proporcionar la portabilidad de las aplicaciones con requerimientos de tiempo real. Junto a las interfases de servicios del sistema, se estandarizan también perfiles de entornos de aplicaciones que permitirán a los implementadores desarrollar sistemas operativos POSIX de tiempo real para una gran variedad de plataformas, desde los sistemas empotrados pequeños hasta los sistemas de tiempo real grandes. El estándar define interfaces en diferentes lenguajes de programación. En particular, las interfaces de tiempo real están siendo definidas para C y Ada, que son los lenguajes estándar de programación más importantes para los sistemas prácticos de tiempo real.
La funcionalidad especificada en el estándar POSIX es similar a la que se encuentra en la mayoría de los núcleos y sistemas operativos de tiempo real disponibles comercialmente. Las interfases POSIX se han definido de acuerdo con resultados recientes de la teoría de planificación con prioridades estáticas. Algunas implementaciones basadas en borradores iniciales de los estándares POSIX.4 y POSIX.4a ya han sido desarrolladas y muestran resultados muy prometedores. En resumen, el estándar POSIX permitirá construir sistemas predecibles y analizables que cumplen sus requerimientos de tiempo real, y que pueden ser fácilmente portables de unas plataformas a otras.
Procesos de Sistemas Operativos – Control de Lectura.

Términos básicos a investigar.

1. Programa.
 2. Procesos.
 3. Hilos.
 4. Hebras.
 5. Multihilos.
 6. POSIX.
7. Servicios del sistema operativo.
 8. API.
9. Sincronización.
 10. Variable global.