1

Procesos e Hilos en los Sistemas Operativos Windows y Linux.
Luis F. Alvear, David A. Álvarez
Resumen—Se presenta un breve resumen de cómo funcionan los procesos e hilos tanto en los sistemas operativos Windows, como para Linux, como se crean y como son tratados por él microprocesador, se analiza cómo se lleva a cabo la compartición de los recursos del sistema, entre otras características. Términos para indexación—WINDOWS, LINUX, Procesos, Hilos.

Los hilos pueden crear hilos hijos y se pueden bloquear en espera de que se terminen sus llamadas al sistema, es algo similar a lo que ocurre con un proceso en una maquina, lo mismo ocurre con un hilo en un proceso. Todos los hilos tienen el mismo espacio de direcciones, lo que implica que comparten las mismas variables locales. Un proceso pertenece a un usuario el cual consta de varios hilos para que cooperen entre si, lo cual implica que los elementos de un proceso son partes de los elementos de un hilo. PROCESOS EN WINDOWS NT

I. PROCESOS E HILOS EN WINDOWS N la totalidad de sistemas operativos, cada proceso tiene un espacio de direcciones y un hilo de control. Pero existen situaciones en las cuales por el tipo de aplicaciones que se tiene necesitan tener varios hilos de control que compartan un espacio de direcciones, pero que se ejecuten de manera simultánea, como si fueren procesos independientes porque es espacio de direcciones si necesariamente lo comparten. Una aplicación de un servidor que debe desactivarse en forma ocasional, en espera de una solicitud al disco, por ejemplo necesita de varios hilos de control, se podría ejecutar un hilo mientras los otros están como secundarios en espera de que sean llamados para lograr esto se necesita trabajar necesariamente con hilos.

E

VER FIGURA 1. (ANEXOS) Como observamos en el gráfico en una computadora se están ejecutando tres procesos los cuales tienen su contador de programa y su pila ( conjunto de registros y de espacios de direcciones). Los procesos no se comunican son independientes unos con otros sin embargo a través de las primitivas del sistema lo pueden hacer como semáforos, monitores o mensajes.
Documento recibido el 14 de Octubre del 2009. Esta investigación se realizó en la Escuela Politécnica Nacional (EPN), como parte del desarrollo de la materia Aplicaciones Distribuidas. L. F. Alvear participó en la investigación como miembro del curso de Aplicaciones Distribuidas (teléfono: 5932-2564-111: e-mail: luis.alvear@meer.gov.ec). D. A. Álvarez participó en la investigación como miembro del curso de Aplicaciones Distribuidas (teléfono: 5932-2259-514: e-mail: david.alvarez@meer.gov.ec).

En el otro extremo del grafico observamos un solo proceso con varios hilos o también llamados procesos ligeros, que se ejecutan en forma estrictamente secuencial y tiene su contador de programa y una pila para llevar un registro de su posición.

El diseño de los procesos de Windows NT está dirigido por la necesidad de dar soporte a varios entornos de sistemas operativos. Los procesos aportados por los distintos sistemas operativos son diferentes en varios aspectos, incluyendo los siguientes: • Cómo se les denomina a los procesos. • Si hay hilos disponibles dentro de los procesos. • Cómo se representan los procesos. • Cómo se protegen los recursos de los procesos. • Qué mecanismos se emplean para la comunicación y la sincronización entre procesos. • Cómo están relacionados los procesos entre sí. Por lo cual, la estructura nativa de los procesos y de los servicios que brinda el núcleo de NT es relativamente simple y de propósito general, permitiendo a cada subsistema emular la estructura y la funcionalidad particular de los procesos de un sistema operativo. Las características más importantes de los procesos de NT son las siguientes: • Los procesos de NT se implementan como objetos. • Un proceso ejecutable puede tener uno o más hilos. • Los objetos proceso y los objetos hilo tienen capacidades predefinidas de sincronización. • El núcleo de NT no conserva ninguna relación entre los procesos que crea, incluyendo las relaciones padre-hijo. El proceso tiene una señal de acceso que le sirve para cambiar sus propios atributos. También tienen que ver con el proceso una serie de bloques que definen el espacio de direcciones virtuales asignado. El proceso no puede modificar directamente estas estructuras, sino que debe depender del administrador de memoria virtual, quien le proporciona al proceso un servicio de asignación de memoria. Finalmente, el proceso incorpora una tabla de objetos, con los descriptores de otros objetos que conoce. Existe un descriptor para cada hilo del proceso. Razones para la Creación de Procesos

2 Terminado: Un proceso que ha sido excluido por el sistema operativo del grupo de procesos ejecutables. VER FIGURA 3. (ANEXOS) Se le asocia un identificador al proceso y se construyen y asignan algunas tablas necesarias para gestionar el proceso. En este punto, el proceso estará en el estado Nuevo. Esto significa que el sistema operativo ha llevado a cabo las acciones necesarias para crear el proceso pero no se ha comprometido aún a su ejecución. Aquí se muestran algunos ejemplos de procesos su estado y el tiempo de ejecución. VER TABLA 1 (ANEXOS) Razones para la Suspensión de procesos Intercambio.- El sistema operativo necesita liberar suficiente memoria principal para cargar un proceso que está listo para ejecutarse. Solicitud de un usuario.- Un usuario puede querer suspender una ejecución de un programa con fines de depuración o en conexión con el uso de un recurso. Por tiempo.- Un proceso puede ejecutarse periódicamente y puede ser suspendido mientras espera el siguiente intervalo de tiempo. Elementos Típicos de una Imagen de Proceso Datos de Usuario.- La parte modificable del espacio de usuario. Puede guardar datos del programa, una zona para una pila del usuario y programas que pueden modificarse. Pila del Sistema Cada proceso tiene una o más pilas (el último que entra es el primero en salir) asociadas a él. Una pila se utiliza para almacenar los parámetros y as direcciones de retorno. Bloque de Control de Proceso Información necesaria para que el sistema operativo controle al proceso. Memoria Virtual en los Procesos. La memoria constituyó hace muchos años las personas enfrentaron por primera vez programas que eran demasiado grandes para caber en la memoria disponible. La solución que normalmente se adoptaba era dividir el programa en fragmentos, llamados superposiciones. La superposición O era la primera que se ejecutaba. Al terminar, esta superposición llamaba a otra. Algunos sistemas de superposición eran muy complejos, pues permitían varias superposiciones en la memoria a la vez. Las superposiciones se mantenían en disco y el sistema operativo las intercambiaba con la memoria dinámicamente, según fuera necesario. Aunque el trabajo real de intercambiar las superposiciones corría por cuenta del sistema, la tarea de dividir el programa en fragmentos tenía que ser efectuada por el programador. La división de programas grandes en fragmentos modulares

Nuevo trabajo por lotes.- El sistema operativo esta provisto de un flujo de control de trabajos por lotes, generalmente para cinta o disco. Cuando el sistema operativo se prepara para tomar un nuevo trabajo, leerá a próxima secuencia de ordenes de control de trabajos. Conexión interactiva.- Un usuario entra en el sistema desde un terminal. Creado por el SO para dar un servicio.- El sistema operativo puede crear un proceso para llevar a cabo una función de parte de un programa usuario, sin que el usuario tenga que esperar (por ejemplo, imprimir). Generado por un proceso existente.- Con afán de modularidad o para aprovechar el paralelismo, un programa de usuario puede ordenar la creación de una serie de procesos. Cuando un proceso es creado por el sistema operativo tras la solicitud explicita de otro proceso, la acción se conoce como generación de procesos. Cuando un proceso genera otro, el proceso generador se conoce como proceso padre y el proceso generado es el proceso hijo. Normalmente, estos procesos “emparentados” necesitarán comunicarse y cooperar entre si. Terminación de procesos En cualquier sistema informático, debe haber alguna forma de que un proceso pueda indicar que ha terminado. Estados de un Proceso Hay una cola sencilla de procesos. Cada entrada de la cola es un puntero a un proceso en particular. Cuando un proceso se interrumpe, se le pasa a la cola de procesos en espera. Por otra parte, si un proceso termina o se abandona, se le descarta del sistema (sale del sistema). En cualquier caso, el, distribuidor selecciona entonces un proceso de la cola para ejecutarlo. VER FIGURA 2 (ANEXOS) Un modelo de cinco estados Algunos procesos en el estado de No Ejecución están listos para ejecutar, mientras que otros están bloqueados, esperando a que termine una operación de E/S. Los procesos esperan cola en una lista en la cual el primero en entrar, es primero en salir. Así pues, utilizando una cola sencilla, el distribuidor podría no seleccionar exactamente el proceso que está en el extremo más antiguo de la cola, por lo cual se han incorporado algunos estados de gran utilidad. Ejecución: El proceso que está actualmente en ejecución. Listo: Proceso que está preparado para ejecutar, en cuanto se le dé la oportunidad. Bloqueados: Proceso que no puede ejecutar hasta que se produzca cierto suceso, como la terminación de una operación de E/S. Nuevo: Proceso que se acaba de crear, pero que aún no ha sido admitido por el sistema operativo en el grupo de procesos ejecutables.

3 pequeños consumía tiempo y era tediosa. No pasó mucho tiempo antes de que a alguien se le ocurriera una forma de dejar todo el trabajo a la computadora. La idea en que se basa la memoria virtual es que el tamaño combinado del programa, los datos y la pila puede exceder la cantidad de memoria física disponible para él. El sistema operativo mantiene en la memoria principal las partes del programa que actualmente se están usando, y el resto en el disco. La memoria virtual también puede funcionar en un sistema de multiprogramación, manteniendo Segmentos de muchos programas en la memoria a la vez. Mientras un programa está esperando que se traiga a la memoria una de sus partes, está esperando E/S y no puede ejecutarse, así que puede otorgarse la CPU a otro proceso, lo mismo que en cualquier otro sistema de multiprogramación. Administración de memoria con mapas de bits Cuando la memoria se asigna dinámicamente, el sistema operativo debe administrarla. En términos generales, hay dos formas de contabilizar la utilización de memoria: mapas de bits y listas libres. En esta sección y en la siguiente examinaremos estos dos métodos por tumo. Con un mapa de bits, la memoria se divide en unidades de asignación, tal vez sólo de unas cuantas palabras o quizá de varios kilobytes. A cada unidad de asignación corresponde un bit del mapa de bits, que es 0 si la unidad está libre y 1 si está ocupada (o viceversa). se muestra una parte de la memoria y el mapa de bits correspondiente. Una parte de la memoria con cinco procesos y tres agujeros. Las marcas indican las unidades de asignación de memoria. Las regiones sombreadas (O en el mapa de bits) están libres, (b) El mapa de bits correspondiente, (e) La misma información en forma de lista. El tamaño de la unidad de asignación es una cuestión de diseño importante. Cuanto menor sea la unidad de asignación, mayor será el mapa de bits. Sin embargo, incluso con una unidad de asignación de sólo cuatro bits, 32 bits de memoria sólo requerirán un bit del mapa. Una memoria de 32n bits usará n bits de mapa, y el mapa sólo ocupará 1/33 de la memoria. Si se escoge una unidad de asignación grande, el mapa de bits será más pequeño, pero podría desperdiciarse una cantidad apreciable de memoria en la última unidad si el tamaño del proceso no es un múltiplo exacto de la unidad de asignación. Un mapa de bits ofrece un método sencillo para contabilizar las palabras en una cantidad fija de memoria, porque el tamaño del mapa de bits depende sólo del tamaño de la memoria y del tamaño de la unidad de asignación. El problema principal que presenta es que una vez que se ha decidido traer a la memoria un proceso de k unidades, el administrador de memoria debe buscar en el mapa de bits una serie de k bits en O consecutivos. La búsqueda de series de una longitud dada en un mapa de bits es una operación lenta (porque la serie puede cruzar fronteras de palabra en el mapa); éste es un argumento en contra de los mapas de bits. Administración de memoria con listas enlazadas Otra forma de contabilizar la memoria es mantener una lista enlazada de segmentos de memoria libres y asignados, donde un segmento es un proceso o bien un agujero entre dos procesos. La memoria se representa en la como lista enlazada de segmentos. Cada entrada de la lista especifica un agujero (H) o un proceso (P), la dirección en la que principia, la longitud y un apuntador a la siguiente entrada. En este ejemplo, la lista de segmentos se mantiene ordenada por dirección. Este ordenamiento tiene la ventaja de que cuando un proceso termina o es intercambiado a disco, es fácil actualizar la lista. Un proceso que termina normalmente tiene dos vecinos (excepto cuando está en el tope o la base de la memoria). Éstos pueden ser procesos o agujeros, dando lugar a las cuatro combinaciones de la actualización de la lista requiere la sustitución de una P por una H. En las dos entradas se funden para dar una sola, y el tamaño de la lista se reduce en una entrada. En las tres entradas se funden y dos elementos se eliminan de la lista. Puesto que la ranura de tabla de procesos para el proceso que va a terminar normalmente apunta a la entrada del proceso mismo en la lista, puede ser más recomendable tener una lista doblemente enlazada, en lugar de la lista con un solo enlace . Esta estructura facilita la localización de la entrada anterior para determinar si es posible una fusión. Cuatro combinaciones de vecinos para el proceso que termina, X. Si los procesos y agujeros se mantienen en una lista ordenada por dirección, se pueden usar varios algoritmos para asignar memoria a un proceso recién creado o traído a la memoria. Suponemos que el administrador de memoria sabe cuánta memoria debe asignar. El algoritmo más sencillo es el de primer ajuste. El administrador de memoria examina la lista de segmentos hasta encontrar un agujero con el tamaño suficiente. A continuación, el agujero se divide en dos fragmentos, uno para el proceso y otro para la memoria desocupada, excepto en el poco probable caso de que el ajuste sea exacto. El algoritmo de primer ajuste es rápido porque la búsqueda es la más corta posible. Una variante menor del primer ajuste es el siguiente ajuste. Este algoritmo funciona igual que el de primer ajuste, excepto que toma nota de dónde está cada vez que encuentra un agujero apropiado. La siguiente vez que se invoque, el algoritmo comenzará a buscar en la lista a partir del lugar donde se quedó la última vez, en lugar de comenzar por el principio, como hace el primer ajuste. Simulaciones ejecutadas demuestran que el siguiente ajuste ofrece un rendimiento ligeramente peor que el primer ajuste. Otro algoritmo bien conocido es el de mejor ajuste, que examina toda la lista y toma el agujero más pequeño que es adecuado. En lugar de partir un agujero grande que podría necesitarse después, el mejor ajuste trata de encontrar un agujero con un tamaño cercano al que se necesita. El mejor ajuste es más lento que el primer ajuste porque debe examinar toda la lista cada vez que se invoca. Lo que resulta sorprendente es que también desperdicia más memoria que el primer ajuste o el siguiente ajuste porque tiende a llenar la memoria de pequeños

4 agujeros inútiles. En promedio, el primer ajuste g nera agujeros más grandes. A fin de sortear el problema de partir un agujero con un tamaño casi igual al requerido para obtener un área asignada al proceso y un agujero diminuto, podríamos considerar el peor ajuste, es decir, tomar siempre el agujero más grande disponible, de modo que el agujero sobrante tenga un tamaño suficiente para ser útil. Las simulaciones han demostrado que el peor ajuste tampoco es una idea muy buena. mediante rodajas de tiempo muy rápidas que dan la sensación de simultaneidad. Para que Linux pueda gestionar los procesos en el sistema, cada proceso se representa por una estructura de datos task_struct (las tareas (task) y los procesos son términos intercambiables en Linux). El vector task es una lista de punteros a estructuras task_struct en el sistema. Esto quiere decir que el máximo número de procesos en el sistema está limitado por el tamaño del vector task; por defecto tiene 512 entradas. A medida que se crean procesos, se crean nuevas estructuras task_struct a partir de la memoria del sistema y se añaden al vector task. Para encontrar fácilmente el proceso en ejecución, hay un puntero (current) que apunta a este proceso. Linux soporta procesos de tiempo real así como procesos normales. Estos procesos tienen que reaccionar muy rápidamente a sucesos externos (de ahí el término “tiempo real”') y reciben un trato diferente del planificador. La estructura task_struct es bastante grande y compleja, pero sus campos se pueden dividir en áreas funcionales: -State (Estado) A medida que un proceso se ejecuta, su estado cambia según las circunstancias. Los procesos en Linux tienen los siguientes estados: - Running (Preparado) El proceso se está ejecutando (es el proceso en curso en el sistema) o está listo para ejecutarse (está esperando a ser asignado a una de las CPUs del sistema). - Waiting (Esperando) El proceso está esperando algún suceso o por algún recurso. Linux diferencia dos tipos de procesos; interrumpibles e ininterrumpibles. Los procesos en espera interrumpibles pueden ser interrumpidos por señales mientras que los ininterrumpibles dependen directamente de sucesos de hardware y no se pueden interrumpir en ningún caso. - Stopped (Detenido) El proceso ha sido detenido, normalmente porque ha recibido una señal. Si se están depurando errores en un proceso, éste puede estar detenido. Zombie Es un proceso que ya ha terminado pero cuya estructura task_struct permanece aún en el vector task. Se suele mantener para que el padre pueda extraer información útil de él. En la Figura 4 (ANEXOS) podemos apreciar el diagrama de estados, sobre los cuales se puede encontrar un proceso en el Sistema Operativo Linux. Información de la Planificación de Tiempo de la CPU El planificador necesita esta información para hacer una decisión justa sobre qué proceso en el sistema se merece más ejecutarse a continuación.

II.PROCESOS E HILOS EN LINUX

El recurso más preciado en el sistema es la CPU; Linux es un sistema operativo multiproceso. Y su principal objetivo es tener siempre un proceso ejecutándose en cada CPU del sistema en todo instante, para maximizar el aprovechamiento del uso de la CPU. Si existen más procesos que CPUs (lo común es este caso), la cola de los procesos tiene que esperar su turno hasta que una CPU quede libre para que ellos ejecutarse. El multiproceso es una idea no muy compleja; un proceso se ejecuta hasta que tenga que esperar, normalmente por algún recurso del sistema; cuando obtenga dicho recurso, puede ejecutarse otra vez. En un sistema uniproceso, por ejemplo DOS, la CPU estaría simplemente esperando estática, y el tiempo que no realiza ninguna Tarea se desaprovecharía. En un sistema multiproceso se mantienen varios procesos en memoria al mismo tiempo. Cuando un proceso tiene que pasar a un estado de espera, el sistema operativo le quita la CPU a ese proceso y se la da a otro proceso que le corresponda o que tenga mayor prioridad. El planificador se encarga de elegir el proceso más apropiado el cuál se deba ejecutar a continuación. Linux usa diferentes estrategias de organización del tiempo de la CPU para tratando de hacerlo de la mejor manera (lo reparte de manera justa). Hablar tanto de Procesos como de Hilos, es hablar de dos conceptos muy similares y relacionados entre sí, entre los cuales existen pequeñas diferencias nada más. Uno de los principales motivos de la existencia de la informática es imitar el comportamiento de la mente humana. En un comienzo surgieron los algoritmos, que no son más que una secuencia de pasos para conseguir un objetivo, a partir de los cuales surgió el pensamiento de “por qué no hacer varias cosas a la vez” y es precisamente de esta inquietud de donde surgen los hilos o threads. Si queremos que nuestro programa empiece a ejecutar varias cosas "a la vez", tenemos dos opciones. Por una parte podemos crear un nuevo proceso y por otra, podemos crear un nuevo hilo de ejecución (un thread). En realidad nuestro ordenador, salvo que tenga varias CPU’s, no ejecutará varias tareas a la vez esto se refiere a que el sistema operativo, es este caso Linux, irá ejecutando los threads según la política del mismo, siendo lo mas usual

5 Identificadores Cada proceso en el sistema tiene un identificador de proceso. El identificador no es un índice en el vector task, es simplemente un número. Cada proceso también tiene identificadores de usuario y grupo, que se usan para controlar el acceso de este proceso a los ficheros y los dispositivos del sistema. Enlaces En un sistema de Linux ningún proceso es independiente de otro proceso. Cada proceso en el sistema, excepto el proceso inicial (init), tiene un proceso padre. Los procesos nuevos no se crean, se copian, o más bien se clonan de un proceso existente. Cada estructura task_struct que representa un proceso mantiene punteros a su proceso padre y sus hermanos (los procesos con el mismo proceso padre) así como a sus propios procesos hijos. Se pueden ver las relaciones entre los procesos en ejecución en un sistema Linux con la orden pstree: init(1)-+-crond(98) |-emacs(387) |-gpm(146) |-inetd(110) |-kerneld(18) |-kflushd(2) |-klogd(87) |-kswapd(3) |-login(160)---bash(192)---emacs(225) |-lpd(121) |-mingetty(161) |-mingetty(162) |-mingetty(163) |-mingetty(164) |-login(403)---bash(404)---pstree(594) |-sendmail(134) |-syslogd(78) `-update(166) Además, todos los procesos en el sistema también están en una doble lista encadenada cuya raíz es la estructura task_struct del proceso init. Esta lista permite al núcleo de Linux observar cada proceso del sistema. Tiempos y Temporizadores El núcleo mantiene conocimiento de la hora de creación de los procesos así como el tiempo de CPU que consume a lo largo de su vida. En cada paso del reloj, el núcleo actualiza la cantidad de tiempo en jiffies que el proceso en curso ha usado en los modos sistema y usuario. Linux también soporta temporizadores de intervalo específicos a cada proceso; los procesos pueden usar llamadas del sistema para instalar temporizadores para enviarse señales a sí mismos cuando el temporizador acaba. Estos temporizadores pueden ser de una vez, o periódicos. Sistema de Ficheros Los procesos pueden abrir y cerrar ficheros y la estructura task_struct de un proceso contiene punteros a los descriptores de cada fichero. Contexto Específico del Procesador Un proceso se puede ver como la suma total del estado actual del sistema. Cuando un proceso se ejecuta, está utilizando los registros, las pilas, etc, del procesador. Todo esto es el contexto del procesador, y cuando se suspende un proceso, todo ese contenido específico de la CPU se tiene que salvar en la estructura task_struct del proceso. Cuando el planificador reinicia un proceso, su contexto se pasa a la CPU para seguir ejecutándose.

Planificación
Todos los procesos se ejecutan parcialmente en modo usuario y parcialmente en modo sistema. La manera como el hardware soporta estos modos varía, pero en general hay un mecanismo seguro para pasar de modo usuario a modo sistema y viceversa. El modo usuario tiene muchos menos privilegios que el modo sistema. Cada vez que un proceso hace una llamada de sistema, cambia de modo usuario a modo sistema y sigue ejecutándose. Llegado este punto, el núcleo se está ejecutando por el proceso. En Linux, un proceso no puede imponer su derecho sobre otro proceso que se esté ejecutando para ejecutarse él mismo. Cada proceso decide dejar la CPU que está usando cuando tiene que esperar un suceso en el sistema. Por ejemplo, un proceso puede estar esperando a leer un carácter de un fichero. Esta espera sucede dentro de la llamada de sistema, en modo sistema; el proceso utiliza una función de una biblioteca para abrir y leer el fichero y la función, a su vez, hace una llamada de sistema para leer bites del fichero abierto. En este caso el proceso en espera será suspendido y se elegirá a otro proceso para ejecutarse. Los procesos siempre están haciendo llamadas de sistema y por esto necesitan esperar a menudo. Aún así, si un proceso se ejecuta hasta que tenga que esperar, puede ser que llegue a usar una cantidad de tiempo de CPU desproporcionada y por esta razón Linux usa planificación con derecho preferente. Usando esta técnica, se permite a cada proceso ejecutarse durante poco tiempo, 200 ms, y cuando ese tiempo ha pasado, otro proceso se selecciona para ejecutarse y el proceso original tiene que esperar un tiempo antes de ejecutarse otra vez. Esa pequeña cantidad de tiempo se conoce como una porción de tiempo. El planificador tiene que elegir el proceso que más merece ejecutarse entre todos los procesos que se pueden ejecutar en el sistema. Un proceso ejecutable es aquel que está esperando solamente a una CPU para ejecutarse, es decir, está en estado de Preparado (Running). Linux usa un algoritmo razonablemente simple para planificar las prioridades y elegir un proceso entre los procesos que hay en el sistema. Cuando ha elegido un nuevo proceso para ejecutar, el planificador salva el estado del proceso en curso, los registros específicos del procesador y otros contextos en la estructura de datos task_struct. Luego restaura el estado del nuevo proceso (que también es específico a un procesador) para ejecutarlo y da control del sistema a ese proceso. Para que el planificador asigne el tiempo de la CPU justamente entre los procesos ejecutables en el sistema, el planificador mantiene cierta información en la estructura task_struct de cada proceso: policy (política)

6 Esta es la política de planificación que se aplicará a este proceso. Hay dos tipos de procesos en Linux, normales y de tiempo real. Los procesos de tiempo real tienen una prioridad más alta que los otros. Si hay un proceso de tiempo real listo para ejecutarse, siempre se ejecutará primero. Los procesos de tiempo real pueden tener dos tipos de políticas: ”round robin” (en círculo) y ”first in first out” (el primero en llegar es el primero en salir). En la planificación “round robin”, cada proceso de tiempo real ejecutable se ejecuta por turnos, y en la planificación ”first in, first out” cada proceso ejecutable se ejecuta en el orden que están en la cola de ejecución y el orden no se cambia nunca. priority (prioridad) Esta es la prioridad estática que el planificador dará a este proceso. También es la cantidad de tiempo (en jiffies) que se permitirá ejecutar a este proceso una vez que sea su turno de ejecución. Se puede cambiar la prioridad de un proceso mediante una llamada de sistema y la orden renice. rt_priority (prioridad de tiempo real) Linux soporta procesos de tiempo real y estos tienen una prioridad más alta que todos los otros procesos en el sistema que no son de tiempo real. Este campo permite al planificador darle a cada proceso de tiempo real una prioridad relativa. La prioridad del proceso de tiempo real se puede alterar mediante llamadas de sistema. counter (contador) Esta es la cantidad de tiempo (en jiffies) que se permite ejecutar a este proceso. Se decrementa a cada paso de reloj y cuando el proceso se ejecuta y lo consume por completo se iguala a priority. El planificador se ejecuta desde distintos puntos dentro del núcleo. Se ejecuta después de poner el proceso en curso en una cola de espera y también se puede ejecutar al finalizar una llamada de sistema, exactamente antes de que un proceso vuelva al modo usuario después de estar en modo sistema. También puede que el planificador se ejecute porque el temporizador del sistema haya puesto el contador counter del proceso en curso a cero. Cada vez que el planificador se ejecuta, hace lo siguiente: Proceso en curso El proceso en curso tiene que ser procesado antes de seleccionar a otro proceso para ejecutarlo. Si la política de planificación del proceso en curso es round robin entonces el proceso se pone al final de la cola de ejecución. Si la tarea es INTERRUMPIBLE y ha recibido una señal desde la última vez que se puso en la cola, entonces su estado pasa a ser RUNNING (Preparado). Si el proceso en curso a consumido su tiempo, su estado pasa a ser RUNNING (Preparado). Si el proceso en curso está RUNNING (Preparado), permanecerá en ese estado. Los procesos que no estén ni RUNNING (Preparados) ni sean INTERRUMPIBLE se quitan de la cola de ejecución. Esto significa que no se les considerará para ejecución cuando el planificador busque un proceso para ejecutar. Selección de un proceso El planificador mira los procesos en la cola de ejecución para buscar el que más se merezca ejecutarse. Si hay algún proceso de tiempo real (aquellos que tienen una política de planificación de tiempo real) entonces éstos recibirán un mayor peso que los procesos ordinarios. El peso de un proceso normal es su contador counter pero para un proceso de tiempo real es su contador counter más 1000. Esto quiere decir que si hay algún proceso de tiempo real que se pueda ejecutar en el sistema, estos se ejecutarán antes que cualquier proceso normal. El proceso en curso, que ha consumido parte de su porción de tiempo (se ha decrementado su contador counter) está en desventaja si hay otros procesos con la misma prioridad en el sistema; esto es lo que se desea. Si varios procesos tienen la misma prioridad, se elige el más cercano al principio de la cola. El proceso en curso se pone al final de la cola de ejecución. En un sistema equilibrado con muchos procesos que tienen las mismas prioridades, todos se ejecutarán por turnos. Esto es lo que conoce como planificación Round Robin (en círculo). Sin embargo, como los procesos normalmente tienen que esperar a obtener algún recurso, el orden de ejecución tiende a verse alterado. Cambiar procesos Si el proceso más merecedor de ejecutarse no es el proceso en curso, entonces hay que suspenderlo y poner el nuevo proceso a ejecutarse. Cuando un proceso se está ejecutando, está usando los registros y la memoria física de la CPU y del sistema. Cada vez que el proceso llama a una rutina le pasa sus argumentos en registros y puede poner valores salvados en la pila, tales como la dirección a la que regresar en la rutina que hizo la llamada. Así, cuando el planificador se ejecuta, se ejecuta en el contexto del proceso en curso. Estará en un modo privilegiado (modo núcleo) pero aún así el proceso que se ejecuta es el proceso en curso. Cuando este proceso tiene que suspenderse, el estado de la máquina, incluyendo el contador de programa (program counter, PC) y todos los registros del procesador se salvan en la estructura task_struct. A continuación se carga en el procesador el estado del nuevo proceso. Esta operación es dependiente del sistema; diferentes CPUs llevan esta operación a cabo de maneras distintas, pero normalmente el hardware ayuda de alguna manera. El cambio del contexto de los procesos se lleva a cabo al finalizar el planificador. Por lo tanto, el contexto guardado para el proceso anterior es una imagen instantánea del contexto del hardware del sistema tal y como lo veía ese proceso al final del planificador. Igualmente, cuando se carga el contexto del nuevo proceso, también será una imagen instantánea de cómo estaban las cosas cuando terminó el planificador, incluyendo el contador de programa (program counter, PC) de este proceso y los contenidos de los registros.

7 decir, acceden a las mismas variables globales o dinámicas, por lo que no necesitan costosos mecanismos de comunicación para sincronizarse. Por ejemplo un hilo podría encargarse de la interfaz gráfica (iconos, botones, ventanas), mientras que otro hace una larga operación internamente. De esta manera el programa responde más ágilmente a la interacción con el usuario. En sistemas operativos que proveen facilidades para los hilos, es más rápido cambiar de un hilo a otro dentro del mismo proceso, que cambiar de un proceso a otro. Es posible que los hilos requieran de operaciones atómicas para impedir que los datos comunes sean cambiados o leídos mientras estén siendo modificados. El descuido de esto puede generar estancamiento. La Tabla 2 (ANEXOS) resume algunas diferencias entre procesos e hilos, y la Figura 5 (ANEXOS) muestra una representación de los conceptos proceso e hilo. Nótese cómo en la figura 5 (ANEXOS) se puede apreciar que los procesos son entidades independientes, mientras que los hilos son entidades relacionadas por la sección de datos en el interior del proceso que los contiene.

Es importante diferenciar entre el algoritmo de planificación propiamente dicho, y el cambio de contexto: - El algoritmo de planificación únicamente tiene que decidir cuál será el siguiente proceso que utilizará el procesador. Se elige un proceso ganador entre todos los que no están bloqueados. - El cambio de contexto es el mecanismo que efectivamente pone en ejecución a un proceso. Esta operación es muy dependiente de la arquitectura del procesador sobre el que se esté ejecutando, por lo que se tiene que realizar a bajo nivel (en ensamblador).

Procesos
Un proceso es un concepto manejado por el sistema operativo que consiste en el conjunto formado por: • Las instrucciones de un programa destinadas a ser ejecutadas por el microprocesador. • Su estado de ejecución en un momento dado, esto es, los valores de los registros de la CPU para dicho programa. • Su memoria de trabajo, es decir, la memoria que ha reservado y sus contenidos. • Otra información que permite al sistema operativo su planificación. En un sistema Linux, que como ya sabemos es multitarea (sistema operativo multihilo), se pueden estar ejecutando distintas acciones a la par, y cada acción es un proceso que consta de uno o más hilos, memoria de trabajo compartida por todos los hilos e información de planificación. Cada hilo consta de instrucciones y estado de ejecución. Cuando ejecutamos un comando en el shell, sus instrucciones se copian en algún sitio de la memoria RAM del sistema para ser ejecutadas. Cuando las instrucciones ya cumplieron su cometido, el programa es borrado de la memoria del sistema, dejándola libre para que más programas se puedan ejecutar a la vez. Por tanto cada uno de estos programas son los procesos. Los procesos son creados y destruidos por el sistema operativo, pero lo hace a petición de otros procesos. El mecanismo por el cual un proceso crea otro proceso se denomina bifurcación (fork). Los nuevos procesos son independientes y no comparten memoria (es decir, información) con el proceso que los ha creado. En definitiva, es posible crear tanto hilos como procesos. La diferencia estriba en que un proceso solamente puede crear hilos para sí mismo y en que dichos hilos comparten toda la memoria reservada para el proceso.

REFERENCIAS
[1] http://www.monografias.com/trabajos26/estados-proceso-hilos/estadosproceso-hilos.shtml#proceslinux [2] http://www.chuidiang.com/clinux/procesos/procesoshilos.php [3] http://www.ldc.usb.ve/~figueira/Cursos/AdminRedesTelematica/Materia l/procesos.pdf [4] http://www.esdebian.org/linux/28621/los-procesos-linux [5] http://sopa.dis.ulpgc.es/ii-dso/leclinux/procesos/fork/LEC7_FORK.pdf [6] http://sopa.dis.ulpgc.es/iidso/leclinux/procesos/planificador/LEC6_CHEDULER.pdf. [7] http://sopa.dis.ulpgc.es/iidso/leclinux/procesos/planificador/LEC6_SCHEDULER.pdf [8] TANENBAUM S. Andrew, WOODHULL Albert, Sistemas Operativos Distribuidos, Editorial Pretince Hall Hispanoamérica S.A. [9] TANENBAUM S. Andrew, WOODHULL Albert, Sistemas Operativos Diseño e Implementación, Editorial Pretince Hall Hispanoamérica S.A, Segunda Edición. [10] STALLINS Willian, Sistemas Operativos, Editorial Pretince Hall Hispanoamérica S.A;Segunda Edición.

Hilos
Los hilos son similares a los procesos ya que ambos representan una secuencia simple de instrucciones ejecutada en paralelo con otras secuencias. Los hilos son una forma de dividir un programa en dos o más tareas que corren simultáneamente, compitiendo, en algunos casos, por la CPU. La diferencia más significativa entre los procesos y los hilos, es que los primeros son típicamente independientes, llevan bastante información de estados, e interactúan sólo a través de mecanismos de comunicación dados por el sistema. Por otra parte, los hilos generalmente comparten la memoria, es

Luis F. Alvear Nació en Quito-Ecuador el 27 de Junio de 1987. Realizó sus estudios secundarios en el Colegio Particular Técnico Industrial “Hermano Miguel”, donde obtuvo el título de “Bachiller en Ciencias” y “Auxiliar en Manejo de Equipos de Cómputo” en el año 2004. En el mismo año ingresó a la Escuela Politécnica Nacional (EPN), donde actualmente estudia la carrera de Ingeniería Electrónica y Redes de la Información. David A. Álvarez Nació en Quito el 26 de Marzo de 1987. Realizó sus estudios secundarios en el colegio Particular Técnico “Hermano

8 Miguel” de la ciudad de Latacunga, donde obtuvo el bachillerato. En el 2004 ingresó a la Escuela Politécnica Nacional.

ANEXOS:

Figura 1.

Figura 2.

Figura 3.

Figura 4. Estados de un proceso en Linux

9

Figura 5. Relación entre procesos e hilos

Tabla 1.

Tabla 2 Diferencias entre Procesos e Hilos PROCESOS HILOS Manejados por el S.O. Manejados por los procesos Independientes de otros Relacionados con otros procesos. hilos del mismo proceso. Memoria privada, se necesitan Memoria compartida con el mecanismos de comunicación resto de hilos que forman el para compartir información. proceso.

Master your semester with Scribd & The New York Times

Special offer for students: Only $4.99/month.

Master your semester with Scribd & The New York Times

Cancel anytime.