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.
I. PROCESOS E HILOS EN WINDOWS
E
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.
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.

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
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

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.
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

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
3
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

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.
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
4
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.
 5

Identificadores Un proceso se puede ver como la suma total del estado

Cada proceso en el sistema tiene un identificador de proceso. actual del sistema. Cuando un proceso se ejecuta, está
El identificador no es un índice en el vector task, es utilizando los registros, las pilas, etc, del procesador. Todo
simplemente un número. Cada proceso también tiene esto es el contexto del procesador, y cuando se suspende un
identificadores de usuario y grupo, que se usan para controlar proceso, todo ese contenido específico de la CPU se tiene
el acceso de este proceso a los ficheros y los dispositivos del que salvar en la estructura task_struct del proceso. Cuando el
sistema. planificador reinicia un proceso, su contexto se pasa a la
CPU para seguir ejecutándose.
Enlaces
En un sistema de Linux ningún proceso es independiente de Planificación
otro proceso. Cada proceso en el sistema, excepto el proceso
Todos los procesos se ejecutan parcialmente en modo
inicial (init), tiene un proceso padre. Los procesos nuevos no
usuario y parcialmente en modo sistema. La manera como el
se crean, se copian, o más bien se clonan de un proceso
hardware soporta estos modos varía, pero en general hay un
existente. Cada estructura task_struct que representa un
mecanismo seguro para pasar de modo usuario a modo
proceso mantiene punteros a su proceso padre y sus
sistema y viceversa. El modo usuario tiene muchos menos
hermanos (los procesos con el mismo proceso padre) así
privilegios que el modo sistema. Cada vez que un proceso
como a sus propios procesos hijos. Se pueden ver las
hace una llamada de sistema, cambia de modo usuario a
relaciones entre los procesos en ejecución en un sistema
modo sistema y sigue ejecutándose. Llegado este punto, el
Linux con la orden pstree:
núcleo se está ejecutando por el proceso.
En Linux, un proceso no puede imponer su derecho sobre
init(1)-+-crond(98)
otro proceso que se esté ejecutando para ejecutarse él mismo.
|-emacs(387)
Cada proceso decide dejar la CPU que está usando cuando
|-gpm(146)
tiene que esperar un suceso en el sistema. Por ejemplo, un
|-inetd(110)
proceso puede estar esperando a leer un carácter de un
|-kerneld(18)
fichero. Esta espera sucede dentro de la llamada de sistema,
|-kflushd(2)
en modo sistema; el proceso utiliza una función de una
|-klogd(87)
biblioteca para abrir y leer el fichero y la función, a su vez,
|-kswapd(3)
hace una llamada de sistema para leer bites del fichero
|-login(160)---bash(192)---emacs(225)
abierto. En este caso el proceso en espera será suspendido y
|-lpd(121)
se elegirá a otro proceso para ejecutarse.
|-mingetty(161)
|-mingetty(162)
Los procesos siempre están haciendo llamadas de sistema
|-mingetty(163)
y por esto necesitan esperar a menudo. Aún así, si un proceso
|-mingetty(164)
se ejecuta hasta que tenga que esperar, puede ser que llegue a
|-login(403)---bash(404)---pstree(594)
usar una cantidad de tiempo de CPU desproporcionada y por
|-sendmail(134)
esta razón Linux usa planificación con derecho preferente.
|-syslogd(78)
Usando esta técnica, se permite a cada proceso ejecutarse
`-update(166)
durante poco tiempo, 200 ms, y cuando ese tiempo ha
pasado, otro proceso se selecciona para ejecutarse y el
Además, todos los procesos en el sistema también están en
proceso original tiene que esperar un tiempo antes de
una doble lista encadenada cuya raíz es la estructura
ejecutarse otra vez. Esa pequeña cantidad de tiempo se
task_struct del proceso init. Esta lista permite al núcleo de
conoce como una porción de tiempo. El planificador tiene
Linux observar cada proceso del sistema.
que elegir el proceso que más merece ejecutarse entre todos
los procesos que se pueden ejecutar en el sistema. Un
Tiempos y Temporizadores
proceso ejecutable es aquel que está esperando solamente a
El núcleo mantiene conocimiento de la hora de creación de
una CPU para ejecutarse, es decir, está en estado de
los procesos así como el tiempo de CPU que consume a lo
Preparado (Running).
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
Linux usa un algoritmo razonablemente simple para
usado en los modos sistema y usuario. Linux también soporta
planificar las prioridades y elegir un proceso entre los
temporizadores de intervalo específicos a cada proceso; los
procesos que hay en el sistema. Cuando ha elegido un nuevo
procesos pueden usar llamadas del sistema para instalar
proceso para ejecutar, el planificador salva el estado del
temporizadores para enviarse señales a sí mismos cuando el
proceso en curso, los registros específicos del procesador y
temporizador acaba. Estos temporizadores pueden ser de una
otros contextos en la estructura de datos task_struct. Luego
vez, o periódicos.
restaura el estado del nuevo proceso (que también es
específico a un procesador) para ejecutarlo y da control del
Sistema de Ficheros
sistema a ese proceso. Para que el planificador asigne el
Los procesos pueden abrir y cerrar ficheros y la estructura
tiempo de la CPU justamente entre los procesos ejecutables
task_struct de un proceso contiene punteros a los descriptores
en el sistema, el planificador mantiene cierta información en
de cada fichero.
la estructura task_struct de cada proceso:
Contexto Específico del Procesador policy (política)

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.
Cambiar procesos
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.
6
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.
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.

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.
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
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.
REFERENCIAS
[1] http://www.monografias.com/trabajos26/estados-proceso-hilos/estados-
proceso-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/ii-
dso/leclinux/procesos/planificador/LEC6_CHEDULER.pdf.
[7] http://sopa.dis.ulpgc.es/ii-
dso/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.
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.