TECNOLOGÍAS DE LA INFORMACIÓN

EN LINEA
SISTEMAS OPERATIVOS
3 créditos

Profesor Autor: Jose Luis Chauca

Titulaciones Semestre

 SISTEMAS OPERATIVOS Segundo

Tutorías: El profesor asignado se publicará en el entorno virtual de aprendizaje

[Link], y sus horarios de conferencias se indicarán en la sección.

CAFETERÍA VIRTUAL

PERÍODO OCTUBRE 2021/ FEBRERO 2022

[Link]
 TABLA DE CONTENIDO

Resultado de aprendizaje de la asignatura ..................................................................................................... 4

Unidad 2: Procesos e Hilos .............................................................................................................................. 4
Resultado de aprendizaje de la unidad: ...................................................................................................... 4
Tema 1: Procesos ........................................................................................................................................ 4
Ahora si ¿qué es el proceso y como se lo trata Linux? ............................................................................ 6
Estado de los procesos .......................................................................................................................... 11
Control de procesos .............................................................................................................................. 25
PID (Process ID) y PPID (Parent Process ID) .......................................................................................... 29
Multiprogramación y conmutación de tareas. ...................................................................................... 32
Planificación de procesos ...................................................................................................................... 43
Tema 2: Hilos (Threads) ............................................................................................................................. 54
Conceptos de hilos ................................................................................................................................ 54
Algoritmos de planificación. .................................................................................................................. 55
Gestión de procesos .............................................................................................................................. 80
Planificación del procesador o CPU ....................................................................................................... 81
Bibliografía..................................................................................................................................................... 83

i
Organización de la lectura para el estudiante por semana del compendio

Semanas Compendio
Semana 1 Páginas 3 - 19
Semana 2 Páginas 20 - 53
Semana 3 Página 54 – 78
Semana 4 Página 79 – 81

3
RESULTADO DE APRENDIZAJE DE LA ASIGNATURA

Conocer los conceptos fundamentales, partiendo del enfoque clásico de los sistemas operativos
como administrador eficiente de recursos, componentes, estructuras y funciones de los sistemas
operativos, con la finalidad que entiendan el funcionamiento y puedan realizar software de
sistemas.

SISTEMAS OPERATIVOS

UNIDAD 2: PROCESOS E HILOS

Resultado de aprendizaje de la unidad:

Describir la importancia de la planificación, la comunicación y la sincronización de procesos e hilos

en sistemas de multiprocesamiento.

Tema 1: Procesos

En un sistema multiprogramado o de tiempo compartido (que aparecieron por los 70 con el

surgimiento del microprocesador), un proceso es la imagen en memoria de un programa, junto
con la información relacionada con el estado de su ejecución, o simplemente una secuencia de
instrucciones ejecutándose en ese instante de tiempo.
Un programa es una entidad pasiva, una lista de instrucciones; un proceso es una entidad activa,
que define la actuación que tendrá el sistema.

En contraste 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.
Por lo tanto, un proceso puede caracterizarse de manera única, y esencialmente consta de dos
elementos, el código del programa (program code) y un conjunto de datos (set of data) asociados
con ese código, los cuales se almacenan en memoria durante la ejecución de dicho proceso, ahora
para conocer el estado actual del proceso, la CPU se apoya en el contador de programa (program
counter, PC), cuyo valor almacena la dirección de memoria del código en ejecución, que está
almacenado en esa dirección de memoria, además de los valores almacenados en ese instante en
los registros del procesador. El diseño en memoria de un proceso generalmente se divide en varias
secciones como se muestra en la Figura 2.1.
Estas secciones incluyen:

4
  Texto (Text) – Esta sección almacena el código ejecutable
 Datos (Data) – Esta sección almacena las variables globales
 Amontonar o montón (Heap) – Esta sección, representa el
almacenamiento dinámico de memoria, el cual se va amontonando
o asignando a medida que el programa se está ejecutando, durante
el tiempo que dure su ejecución.
 Pila (Stack) – Esta sección es un almacenamiento temporal de
datos (parámetros, variables locales, direcciones de retorno, etc),
lo cuales van apilándose y desapilándose a medida que una función
es llamada o autollamada (función recursiva).
Figura 2.1: Distribución de
Es importante tomar en cuenta que las secciones de texto y datos tienen un proceso en memoria.
un tamaño fijo, es decir no cambian durante su ejecución, pero los
tamaños en memoria de las secciones de pila y montón se van a ajustando dinámicamente según
el programa en ejecución lo requiera. Se debe tomar en cuenta como trabaja la pila, cada vez que
una función es llamada, al igual que sus parámetros, variables locales y dirección de retorno los
cuales son almacenados en un registro de activación, y este es insertado (pushed) en la pila,
proceso que seguirá, mientras la función sea llamada una y otra vez, apilando un registro de
activación sobre otro, hasta que la función deje de ser solicitada por el proceso, luego de esto, es
devuelto (returned) el control desde la función y los registro de activación que fueron apilados,
son tomados (popped) de la pila, hasta dejarla vacía. Similar sucede con el montón, porque este
crecerá a medida que la memoria sea asignada dinámicamente y se reducirá cuando la memoria
sea regresada al sistema. Aunque las secciones de pila y el montón crezcan dinámicamente la una
hacia (toward) la otra, el sistema operativo debe asegurar de que no haya sobre posición (overlap)
entre ellas (Serna, 2020, p.109).

Recuerda que:
Se debe tener cuidado porque los tamaños en memoria de las secciones de
pila y montón jamás puede superar la capacidad máxima de la memoria física.

Es importante detallar que un programa por sí mismo no es un proceso, porque mientras no se

esté ejecutando es una entidad pasiva, el cual puede ser un archivo con un conjunto de instrucción
que está almacenado en algún lugar, este puede ser cualquier archivo que tenga características
ejecutable e interpretables por el sistema y que está a la espera de ser ejecutado o no, por su lado
un proceso es una entidad activa, que está en ejecución, y mientras se está ejecutando, el contador
de programa está a la expectativa de cuál debe ser la siguiente instrucción a ejecutar, además de
otros recursos asociados. Ahora, un programa se convierte en un proceso cuando este archivo
ejecutable se carga en la memoria. Es más, un mismo programa ejecutado varias veces, está
asociado a varios procesos independientes, porque, aunque es el mismo programa, cada secuencia
de ejecución es independiente. Un ejemplo común son las pestanas de un navegador web, cada
una es un proceso independiente (Figura 2.2). Si volvemos a ver la Figura 2.1, cada proceso

5
independientemente tendrá la sección de texto con el mismo contenido, pero los contenidos de
las otras secciones (datos, montón y pila) van a ser distintos.

Figura 2.2: Ejemplo del navegador web Microsoft Edge, ejecutándose en varios procesos

Un proceso en sí mismo, puede ser un entorno de ejecución para otro código, por ejemplo: Los
programas escritos en Java para poder ejecutarse, necesitan que previamente esté ejecutándose
en memoria la máquina virtual de Java (Java Virtual Machine, JVM). La JVM se ejecuta como un
proceso que interpreta el código Java cargado y realiza acciones (a través de las instrucciones de
la máquina nativa) en nombre de ese código.

Ahora si ¿qué es el proceso y como se lo trata Linux?

Un procesos es un programa en ejecución, coloquialmente un proceso es una unidad de actividad

que sigue una secuencias de instrucciones y usa recursos del sistemas como CPU, MEMORIA entre
otros, y tiene un estado actual, que tiene que ver esto con Linux. Linux es un sistema
multiprocesos, esto quiere decir que cada proceso puede actuar al mismo tiempo que otro, sin
que unos interfieran con otros, para aquellos que tienen conocimientos más avanzado y
experimentados sabrán qué esto lo hace por turnos y calendarización los mismo que son pasados
por el kernel de uno en uno, para que el kernel pueda tener este tipo de manejo lo que se suele
usar es un PID, una identificación por sus siglas en inglés (Processing Identification) identificación
de procesos permitiendo que el kernel pueda hacer su trabajo apropiadamente, procedemos en
este apartado a revisar los comando para la ejecución y administración de procesos.

Recuerda que:
Un proceso es una unidad de actividad que sigue una secuencia de
instrucciones y usa recursos del sistemas como CPU, MEMORIA entre otros, y
tiene un estado actual.

6
Práctica 1. Estados de la CPU

Lo primero que debemos realizar es arrancar nuestro sistema operativo, para este ejemplo se va
utilizar los sistemas operativos Linux CentOS 7.9, a pesar que los comando se pueden utilizar en
debían, Ubuntu, Redhat, etc.
Una vez ya dentro del sistema operativo procedemos a abrir una terminal.

Figura 2.3: Escritorio de Linux CentOS 7.9.

Luego en cualquier parte del escritorio damos clic derecho del mouse y escogemos la opción Abrir
terminal como lo indica la .

Figura 2.4: abrir terminal en Linux CentOS 7.9.

Luego de haber ejecutado la terminal procedemos a ingresar el comando top, el mismo que nos
va muestra una interfaz en modo texto que se va a ir actualizando cada 3 segundos. Muestra un
resumen del estado de nuestro sistema y la lista de procesos que se están ejecutando.
[root@localhost ~]# top

La ejecución del comando anterior nos traerá la siguiente ventana con los resultados.

7
 Figura 2.5: Resultado de la ejecución del top, lista de procesos que se están ejecutando.

Interpretación de las diferentes funciones que muestra la lista de procesos que se están
ejecutando en el sistema.
Tiempo de actividad y carga media del sistema

En la primera línea nos muestra:

 Hora actual.
 Tiempo que ha estado el sistema encendido.
 Número de usuarios.
 Carga media en intervalos de 5, 10 y 15 minutos respectivamente.

8
Tareas

La segunda línea muestra el total de tareas y procesos, los cuales pueden estar en diferentes
estados.
 Running (ejecutando): procesos ejecutándose actualmente o preparados para ejecutarse.
 Sleeping (hibernando): procesos dormidos esperando que ocurra algo (depende del
proceso) para ejecutarse.
 Stopped (detenido): ejecución de proceso detenido.
 Zombie: el proceso no está siendo ejecutado. Estos procesos se quedan en este estado
cuando el proceso que los ha iniciado muere (padre).

Estados de la CPU

Esta línea nos muestra los porcentajes de uso del procesador diferenciado por el uso que se le dé.
 us (usuario): tiempo de CPU de usuario.
 sy (sistema): tiempo de CPU del kernel.
 id (inactivo): tiempo de CPU en procesos inactivos.
 wa (en espera): tiempo de CPU en procesos en espera.
 hi (interrupciones de hardware): interrupciones de hardware.
 si (interrupciones de software): tiempo de CPU en interrupciones de software.

Memoria física

 Memoria total: (3344084).

 Memoria utilizada: (1305056).
 Memoria libre: (803580).
 Memoria utilizada por buffer: (1235448).
Memoria virtual

9
  Memoria total: (2621436).
 Memoria libre: (2621436).
 Memoria usada: (0).
 Memoria disponible: (2289936).

Columnas

PID: es el identificador de proceso. Cada proceso tiene un identificador único.

USER (USUARIO): usuario propietario del proceso.
PR: prioridad del proceso. Si pone RT es que se está ejecutando en tiempo real.
NI: asigna la prioridad. Si tiene un valor bajo (hasta -20) quiere decir que tiene más prioridad que
otro con valor alto (hasta 19).
VIRT: cantidad de memoria virtual utilizada por el proceso.
RES: cantidad de memoria RAM física que utiliza el proceso.
SHR: memoria compartida.
S (ESTADO): estado del proceso.
%CPU: porcentaje de CPU utilizado desde la última actualización.
%MEM: porcentaje de memoria física utilizada por el proceso desde la última actualización.
TIME+ (HORA+): tiempo total de CPU que ha usado el proceso desde su inicio.
COMMAND: comando utilizado para iniciar el proceso.

10
 Figura 2.6: Identificación de procesos que se están ejecutando.

De la misma manera se puede identificar el ID del proceso, tenemos información quien está
corriendo el proceso y la cantidad de memoria que está usando el proceso, así tambien el valor de
CPU usado y el nombre del comando, se encuentra un NI que identifica la prioridad que tiene el
proceso, más adelante vamos a ver un ejemplo de cómo cambiar la prioridad del proceso, para
salir de esta vista o terminal solo bastara con presionar la tecla CTRL + C y recuperamos la terminal.
Procedemos a limpiar la pantalla mediante el comando:
[ r o o t @ l oc a l h os t ~ ] # c le a r

Estado de los procesos

Cuando un proceso se está ejecutando, este cambia su estado, el estado de un proceso se define
en parte por actividad que esté realizando actualmente ese proceso. Si nos ponemos en el lugar
del procesador (CPU), cada proceso ejecuta instrucciones tomadas del conjunto de instrucciones
que sólo el CPU puede ejecutar, estas instrucciones son supervisadas por el contador de programa,

11
donde este siempre apunta a la próxima instrucción en ejecutarse, sea esta de un mismo proceso
o de otro.
El comportamiento de un proceso se puede enumerar con la siguiente secuencia de estados, según
la secuencia de las instrucciones que se están ejecutando, ver diagrama de estados en la Figura :

Figura 2.7: Diagrama de estados de los procesos

 Nuevo (New) - Se solicitó al sistema operativo la creación de un proceso, y sus recursos y

estructuras están siendo creadas.
 Listo (Ready) - Está listo para iniciar o continuar su ejecución pero el sistema no le ha asignado
un procesador.
 En ejecución (Running)- 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.

Recuerda que:
Solo un proceso puede ejecutarse en el núcleo de procesador, no importa
cuántos núcleos tenga este. Sin embargo, muchos procesos pueden estar listos
y en espera.

12
Práctica 2. Control de tareas en la CPU

En una terminal procedemos a ingresar comandos más robustos como es ps para ver los procesos
que se están ejecutando en la Shell
[ r oo t @l o c a l h o s t ~ ] # ps

Como se puede observar en la imagen 2.8 nos muestra el ID del proceso y el nombre del proceso

Figura 2.8: Identificación de procesos que se están ejecutando en consola o Shell.

Como podemos apreciar en la figura 2.8, en este caso específico, el proceso bash es padre del
proceso ps, entonces podemos darnos cuenta que solo corre ps, que es lo que estamos realizando,
pero si deseamos ver una forma más arbolada (jerarquica) para identificar quien es padre de quien
y quien es hijo de quien se puede utilizar el comando:
p s a x jf [ r o o t @ l oc a l h os t ~ ] # p s ax j f

Figura 2.9: Identificación de procesos padre y proceso hijo de manera arbolada.

13
 Figura 2.10: Identificación de procesos padre y proceso hijo de manera arbolada.

Como se aprecia en la figura 2.10, el proceso ps axjf es hijo del proceso bash (ver el área
sombreada)
Para tener una mejor apreciación de la estructura de los procesos podemos utilizar un comando
pstree que nos dará mejor vista de cómo están definidos los procesos para este ejemplo.
Utilizamos el comando:
[ r oo t @l o c a l h o s t ~ ] # ps t r e e

14
 Figura 2.11: Identificación de procesos padre y proceso hijo de manera arbolada mediante el comando pstree.

Podemos observar que la información de los procesos obtenidos mediante el comando pstree nos
muestra una escena más arboleada de los procesos que se encuentran en ejecución. Esto es una
forma de ver las visualizaciones de los procesos.
Cabe indicar que cuando se ejecuta un proceso en la consola este puede estar dentro de dos
estados attack y diattack lo que significa que un proceso puede estar atado a la consola o desatado
de la consola, para comando ps es imposible ver el resultado, pero si ejecutamos comando que
tardan en ejecutarse podremos tener una mejor apreciación, ejemplo ejecutamos el comando find
/ > /dev/null lo que va suceder que el proceso se va quedar bloqueado, va bloquear la consola
[ r oo t @l o c a l h o s t ~ ] # fi n d / > / d ev / n ul l

Figura 2.12: Ejecución del comando find.

15
Este es un proceso apegado a la consola y hasta que termine no va devolver el promt, como
solución para evitar el bloqueo de la consola es utilizar el símbolo & al final del comando, esto lo
que va hacer es ejecutar el comando en background (segundo plano):
[ r o o t @ l o c a l h o s t ~ ] # f i n d / > / d e v/ nu l l &

Figura 2.13: Ejecución del comando find pero en segundo plano

De esta manera podemos seguir trabajando en la consola pero eventualmente el proceso termino.
Esto es fundamental cuando se quiere hacer una combinación de ver un archivo de log mediante
el comando tail ejemplo: t a i l –0f / v a r / l og / a p ac h e 2 / a c c e s s . l o g &,
r o o t @ u b u n t u : ~ # t a i l 0 f / v a r / l o g /h tt p d/ a c c e ss . l o g & lo que nos va mostrar
que el proceso corrió con el número de ID y cuando alguien se conecte al puerto 80 del servidor
apache va aparecer una línea de log, para esto vamos a forzarlo desde otra consola ejecutando el
comando t e l n e t l o c a l h o s t 8 0

Antes de realizar este tipo de actividad debemos de instalar el servidor web apache y el servidor
de telnet
[ r o o t @ l o c a l h o s t ~ ] # y u m i n s ta l l ht tp d

[ r o o t @ l o c a l h o s t ~ ] # y u m i n s ta l l te ln e t

Luego de realizar la instalación de cada uno de los demonios procedemos a iniciar el servidor web
apache mediante el comando s y s t e m c tl s t a rt h t t p d . se r v i ce

Luego procedemos a darle los permisos necesarios para leer en consola los logs mediante el
comando:
[ r o o t @ l o c a l h o s t h t t p d ] # c h m od - R g o+ r / v a r / lo g / h tt p d /

Figura 2.13: configuración de permisos de lectura al archivo logs.

16
Luego procedemos a ingresar el comando l s – l a el mismo que permite listar los ficheros que
tiene httpd.

Figura 2.14: Listar los directorios mediante ls -ls.

Podemos observar que el fichero que nos interesa en este caso en access_log y procedemos a
ejecutar el comando
[ r o o t @ l o c a l h o s t h t t p d ] # t a i l - 0 f / va r /l o g / h tt p d / ac c e s s _l o g &

Figura 2.15: Ejecución del comando tail en segundo plano.

Ya en este apartado debemos de abrir dos terminales para realizar la práctica correspondiente

Figura 2.16: Ejecución de dos terminales para la práctica.

Procedemos a ingresar en la consola 2 el comando telnet localhost puerto 80, después enviamos
el mensaje “Prueba de sistemas” como muestra en consola 1

17
 Figura 2.17: Ejecución de dos terminales para la práctica.

Podemos observar que el proceso sigue corriendo en background debido a que puedo seguir
utilizando la consola, y, ¿cómo puedo saber que procesos están corriendo en background dentro
de la consola?, para esto debemos de utilizar el comando jobs (trabajos) el mismo que me dice
cuantos trabajos están corriendo

Figura 2.18: Estado de la Ejecución los procesos.

Si deseamos traer el proceso al frente debemos ejecutar el comando fg foreground (primer plano)
y nos aparecerá en la consola para comprobar que se ha ejecutado correctamente debería
bloquearnos la consola.

18
 Figura 2.19: Estado de la Ejecución los procesos en fg.

Si desde el otro terminal procesos a ejecutar el comando telnet estos son los resultados

Figura 2.20: resultados de la ejecución del comando telnet en fg.

19
 Figura 2.21: Estado de la Ejecución los procesos en fg.

Ejemplo especifico de cómo enviar un proceso a bg background y traerlo de vuela a fg foreground

Nosotros en este nivel podemos utilizar y comprender como funciona la combinación de teclas
Ctrl + Z y Ctrl + C

Figura 2.22: Estado de la Ejecución los procesos en fg.

La figura 2.22 muestra el resultado de ejecutar la combinación de teclas C t r l + Z , lo que nos

da a entender que este comando está corriendo en el sistema, de echo si escribimos en la consola
el comando p s a x f | g r e p t a i l

20
 Figura 2.23: Estado de la Ejecución de los procesos en fg.

Podemos observar en la figura 2.23 que el comando tail es visible, podemos observar que está
pero se encuentra detenido, si ahora vamos a la otra consola 2 y ejecutamos el comando telnet
localhost 80 podemos ver que no se muestra nada en la consola debido a que el procesador no le
está otorgando ciclos de CPU a ese comando, entonces para enviarlo a background ejecutamos
el comando bg

Figura 2.24: Estado de la Ejecución los procesos en ciclos de CPU en bg.

Como observamos el proceso se envió a background mediante el comando bg y de manera

automática podemos ver que muestra la línea que se encolo luego de haber realizado o enviado
el comando telnet, si ahora mediante la línea de telnet volvemos a ejecutar el mismo comando
telnet podremos observar en consola los resultados.
Mucha atención, con el comando foreground fg lo traigo hacia adelante el proceso, con Ctrl + Z lo
detenemos y con el comando background bg lo enviamos devuelta al fondo, con el comando jobs
podemos ver en qué estado se encuentra

21
 Figura 2.25: Estado de la Ejecución los procesos en ciclos de CPU en bg.

Existe un comando que podemos ejecutar es Ctrl + r, ahora podemos ver con un ejemplo cómo
funciona, necesitamos cargar un segundo proceso, para esto ejecutamos el comando
[ r o o t @ l o c a l h o s t ~ ] # t a i l - 0 f / v a r/ lo g /h t t p d /a c c e ss _ l o g | g re p - i
access_log este comando se ejecutara en el foreground ahora debemos presionar la
combinación de teclas Ctrl + z y luego escribir el comando jobs para ver los estados de los
trabajos

Figura 2.26: Ejecución de procesos anidados.

Figura 2.27: Revisión de los trabajos en ejecución fg.

22
Ahora nos apareen que hay 3 programas detenidos y aparece uno con el signo + ese que aparece
con el signo + será el que se seleccionara por defecto al escribir el comando foreground fg

Figura 2.28: Revisión de los trabajos procesos detenidos bg.

Y al presionar CTRL + Z y escribir el comando bg y luego jobs veremos los resultados que ahora se
encuentra en estado de ejecutándose

Figura 2.29: Revisión de los trabajos procesos ejecutándose bg.

Si ahora escribimos el comando fg nos traerá el proceso [2]+ que se puede ver que está en estado
detenido.

Figura 2.30: Recuperación de procesos ejecutándose fg

23
Cabe indicar que se puede especificar el número de ID para definir que procesos se pueden traer
al frente mediante el comando fg y que procesos podemos enviar al fondo fg

Figura 2.31: Recuperación de procesos ejecutándose en bg a fg

Figura 2.32: Procesos ejecutándose en bg.

Como podemos observar en la figura tenemos los tres proceso corriendo en el background, ahora
podemos matar cualquier de estos procesos mediante el comando kill % número de ID del proceso
ejemplo kill %1
[root@localhost ~]# kill %1

Figura 2.33: Matar Procesos mediante el comando kill %1.

Podemos observar que el proceso [1] se encuentra en estado de Terminado

24
Control de procesos

Identificador del
proceso

Estado del proceso

Contador de
programa

Registros Figura 2.34: PCB - Bloque de

Control de Procesos

Límites de la
memoria
Lista de archivos
abiertos

...

Cada proceso es representado en el sistema operativo por un bloque de control de proceso

(Process Control Block, PCB), el cual es un registro especial, en donde un sistema operativo agrupa
toda la información asociada con un proceso específico durante todo su tiempo de ejecución, por
lo tanto, el sistema operativo crea una nueva PCB cada vez que se inicia un nuevo proceso, la
información asociada al proceso durante su ejecución en la PCB, son:

 Identificador del proceso (Process Identificador, PID) – El Process ID, es un número entero
que asigna el kernel de algunos sistemas operativos para identificar un proceso de forma
única.
 Estado del proceso (Process state) – El estado puede ser nuevo, listo, en ejecución, en
espera, detenido, etc.
 Contador de programa (Program counter) – El contador indica la dirección de la siguiente
instrucción que se ejecutará para este proceso.
 Registros de CPU (CPU registers) – Los registros varían en número y tipo, dependiendo de
la arquitectura de la computadora. Incluyen acumuladores, registros de índice, punteros
de pila y registros de uso general, además de cualquier información de código de condición.
Junto con el contador del programa, esta información de estado debe guardarse cuando se
produce una interrupción, para permitir que el proceso continúe correctamente después
cuando se reprograme su ejecución.
 Planificación de la CPU (CPU scheduling) – Esta información incluye una prioridad de
proceso, punteros a las colas de planificación y cualquier otro parámetro de planificación.
 Gestión de memoria (Memory management) – Esta información puede incluir elementos
tales como el valor de los registros base y límite y las tablas de páginas, o las tablas de
segmentos, dependiendo del sistema de memoria utilizado por el sistema operativo.

25
  Estadísticas del proceso (Accounting information) – Esta información incluye la cantidad
de CPU y tiempo real utilizado, límites de tiempo, números de trabajo o proceso, etc.
 Información de estado de E/S (I/O status information) – Esta información incluye la lista
de dispositivos de E/S asignados al proceso, una lista de archivos abiertos, etc.
En resumen, la PCB simplemente sirve como depósito de todos los datos necesarios para iniciar o
reiniciar un proceso, junto con algunos datos de control numérico.

Práctica 3. Prioridades de los procesos.

Para esto debemos de ingresar el comando top [ r o ot @ l oc a l h os t ~ ] # t o p e identificar el

parámetro NI (En él se muestran una lista de valores como: 0, 0, 0 -20) estos valores son la
prioridad que tienen los procesos, esto se lo puede agregar de manera manual, como hacemos
esto, mediante la variable o comando que se le conoce como [ r o o t @ lo c a l h o s t ~ ] # n ic e

Figura 2.35: Identificación de prioridad de procesos comando nice.

Para proceder a cambiar la prioridad de los procesos de -20 manualmente utilizando el comando
NICE, cabe indicar que los valores varían de -20 a 19 siendo -20 el de mayor prioridad y 19 el de
menor prioridad en este caso a el proceso gedit le vamos a colocar el valor de 10, ejemplo nice -
10 gedit
[ r oo t @l o c a l h o s t ~ ] # ni c e - 10 g e di t

26
 Figura 2.36: Prioridad de procesos comando nice.

Para ver los cambios realizado ejecutamos el comando ps –fl –C ”gedit”

[ r o o t @ l o c a l h o s t ~ ] # p s - f l -C " g ed it "

Figura 2.37: Prioridad de procesos establecida comando nice.

Como podemos apreciar la ejecución de la instrucción anterior nos trae el procedo gedit, con el
identificador PID 5218 y con NICE de 10 que fue lo que se realizó.
Para cambiar la prioridad de un proceso en ejecución se utiliza el siguiente comando

Debe tener permiso de administrador, ejecutamos el comando sudo renice –n 6 –p 5218, donde
renice realiza un cambio en caliente del proceso, -n identifica la nueva prioridad número de la
nueva prioridad en este caso 6 y –p especifica el identificador del proceso en este caso 5218
[ r o o t @ l o c a l h o s t ~ ] # r e n i c e -n 6 -p 5 2 18

Figura 2.38: Cambio de prioridad de proceso en caliente comando renice.

27
 Figura 2.39: Resultado de la ejecución del cambio de prioridad del proceso comando renice.

Para ver la nueva prioridad del proceso solo basta con ejecutar el comando p s –f l –C
“ g ed i t”

Figura 2.40: Identificación del proceso con el Nuevo NI.

Descripción de los resultados:

Como se aprecia en la imagen nos dice que la vieja prioridad era 10 y que ahora la nueva prioridad
es 6.

Figura 2.41: Identificación del proceso con la nueva prioridad 6 y la vieja prioridad 10.

28
En la imagen 2.41 podemos identificad una variable llamada PPID. El PPID es conocido como el
Parent Process ID.

PID (Process ID) y PPID (Parent Process ID)

A cada proceso le corresponderá un número PID que le identifica totalmente. Es decir en un

mismo momento es imposible que existan dos procesos con el mismo PID. Lo mismo que todos
los procesos tienen un atributo PID que es el número de proceso que lo identifica en el sistema
también existe un atributo llamado PPID. Este número se corresponde con el número PID del
proceso padre. Todos los procesos deben de tener un proceso que figure como padre pero
entonces que ocurre si un padre muere antes que alguno de sus hijos. En estos casos el proceso
'init' del cual hablaremos en seguida adoptará a estos procesos para que no queden huérfanos.

Práctica 4. Identificación de los procesos

Como liberar la terminal de los procesos

Para realizar este procedimiento debemos de ejecutar el siguiente comando en la terminal
[ r o o t @ l o c a l h o s t ~ ] # g e d it & con el signo ampersand al final del comando lo que
estamos diciendo al proceso que lo envié a segundo plano o background con el objeto de liberar
la terminal y continuar trabajando sobre ella.

Figura 2.42: Envió de un proceso a background.

El procedimiento anterior muestra la imagen de ejecución del proceso gedit &, el mismo que
muestra el PID y el número de trabajos Jobs, esto se da porque el proceso o trabajo está corriendo
en bg background, entonces toma el nombre de Jobs.
Para poder revisar todos los trabajos o jobs simplemente debemos de ejecutar el siguiente
comando sobre la terminal jobs [ r oo t @ l o c a l h o st ~ ]# j o bs

Figura 2.43: Resultado de la ejecución el comando Jobs y los procesos a background.

29
Si deseamos conocer el PID del proceso debemos de ejecutar el comando jobs –l
[root@localhost ~]# jobs –l

Figura 2.44: Obtención del PID del trabajo Jobs.

Si solamente se desea conocer el PID del trabajo podemos ejecutar simplemente el comando jobs
–p
[root@localhost ~]# jobs –p

Figura 2.45: Obtención del PID del trabajo Jobs.

Práctica 5. Como regresar los procesos de background al frente

Para traer los procesos que se están ejecutando en background al frente foreground debemos de
ejecutar el comando [ r o o t @ l o c a l h o s t ~ ]# f g 1 o en vez de fg 1 pueden utilizar %1

Figura 2.46: Mecanismos para reanudar la ejecución de un proceso en primer plano, proceso a foreground.

Con los comandos fg foreground y bg background es posible manipular procesos que estén
suspendidos temporalmente, ya sea porque se les envió una señal de suspensión como STOP (20)

30
o porque al estarlos ejecutando se presionó CTRL-Z. Entonces para reanudar su ejecución en
primer plano usaríamos fg.
CRTL + C Termina el proceso
CRTL +Z Envía un proceso a segundo plano

Figura 2.47: Identificación de procesos en consola.

Con el comando [ r o o t @ l o c a l h o st ~] # ps – f se puede obtener información muy

importante como UID nombre de quien ejecuto el proceso, PID identificador del proceso hijo, PPID
identificador del proceso padre, C que representa el uso del CPU, TIME que identifica cuando se
inició el proceso.
Es posible obtener más información de los procesos y el consumo de recursos, esto mediante el
comando ps –u ejecutado dentro de una consola [ r o o t @ lo c a l h o s t ~ ]# p s – u

Figura 2.48: Identificación de procesos y consumo de recursos en consola.

Como se puede observar en la imagen el comando ps –u muestra el porcentaje de CPU y

porcentaje de memoria RAM y los estados del proceso, S cuando está esperando y R cuando está
ejecutando dentro del procesador, D cuando se encuentra esperando pero ocasionado por una
operación de entrada o de salida, T si esta pausado y Z que es un proceso zombi es decir que ya
está terminado pero sigue en la tabla de procesos del sistema, como se aprecia en la imagen en la
columna STAT se identifica Ssl+ esto se da cuando el proceso está compuesto por hilos del
procesador y R+ identifica que el proceso se ejecuta en primer plano y S si es un proceso padre.

31
Multiprogramación y conmutación de tareas.

Hoy en día una característica muy importante de los sistemas operativos es el poder ejecutar varios
programas a la vez, porque un solo programa no puede tener a la CPU o a los dispositivos de E/S
ocupados todo el tiempo, sin contar que hoy en día los usuarios están ejecutando varias
aplicaciones simultáneamente. Por lo tanto, la multiprogramación (multiprogramming)
incrementa el uso del CPU evitando que este se encuentre desocupado, y aumenta la satisfacción
del usuario, además de organizar los programas para que la CPU siempre tenga al menos uno en
ejecución.
Con esta técnica, el sistema operativo mantiene varios procesos (Figura
2.49) residiendo en memoria simultáneamente (RECUERDE: todo
programa en ejecución reside en memoria) Por lo tanto el sistema
operativo selecciona y ejecuta uno de estos procesos, donde este
puede quedar en espera mientras alguna otra actividad del CPU se está
cumpliendo, ej.: una operación de E/S.
Por esto, en un sistema no multiprogramado, estos solo ejecutan un
proceso a la vez, permitiendo a la CPU se pueda quedar inactiva por
algún tiempo, hasta que este proceso sea reanudado, Ahora, la ventaja
de un sistema multiprogramado con respecto a un no
multiprogramado es que el sistema operativo simplemente cambia a
otro proceso y lo ejecuta. De este modo, cuando un proceso necesita Figura 2.49: Distribución de la
esperar, el CPU, no se queda ocioso, sino que conmuta a otro proceso, memoria en un sistema
multiprogramado
y así sucesivamente. Eventualmente, el primer proceso termina de
esperar y recupera la CPU, completando su ejecución, Por lo tanto,
mientras haya al menos un proceso que necesite ejecutarse o ejecutándose, la CPU nunca estará
inactiva. Por lo cual la multiprogramación trae consigo, la multitarea (multitasking).
Los sistemas multitarea, ejecutan varios procesos en la CPU cambiando entre ellos, esta actividad
produce cambios con tal frecuencia, que proporcionan al usuario un tiempo de respuesta rápida
de tal forma que los usuarios pueden interactuar con cada programa, mientras este está en
ejecución. Normalmente el tiempo de ejecución de un proceso, desde que inicia y hasta que
termina) es corto o simplemente dura hasta que el usuario necesite una operación de E/S (Cura,
2020, P.229).

Sabías que:
Las operaciones de entrada y salida (E/S) son interactivas, es decir que el
usuario está interactuando con el sistema enviando datos hacia este a través
de periféricos de entrada como el teclado, el ratón, etc., de igual forma que
el sistema operativo responde a este mostrando información al usuario a
través de dispositivos de salida como el monitor, parlantes, impresora, etc.,
procesos que se ejecutan a la “velocidad de un humano”, por lo cual puede
demorar en ejecutar y completarse. Porque a pesar de ser rápido para un ser
humano, es MUY lento para el CPU.

32
Por lo tanto, mientras un usuario completa un proceso de E/S, el sistema operativo en vez de dejar
al CPU quedarse inactivo, rápidamente lo pondrá a realizar otro proceso.
Para poder tener varios procesos en memoria al mismo tiempo, es necesario que ser realice una
gestión en la memoria, tema que veremos más adelante en la última unidad de esta asignatura,
adicional a esto, recordando lo que hemos visto anteriormente, varios procesos podrían estar
listos (ready, según el diagrama de estado de la Figura 2.7), por lo cual es sistema operativo debe
elegir qué proceso se ejecutará en ese instante, para esto el sistema operativo realiza una toma
de decisiones a través de una planificación de la CPU (CPU scheduling). Por lo cual, en un entorno
multitareas, el sistema operativo debe garantizar un tiempo de respuesta razonable, y a veces un
proceso puede necesitar más memoria de la que existe físicamente, lo cual podría causar un
desbordamiento de esta, entonces un método que utiliza el sistema operativo para evitar esto, es
utilizar la memoria virtual (tema que veremos en la última unidad).

Práctica 6. Procesos anidados

El comando para ingresar a una sesión dentro de la misma sesión es: s u –

Figura 2.50: Ejecución de procesos anidados en consola.

Mediante el comando ps f podemos observar la sesión creada de una manera arborizada:

[root@localhost ~]# ps f

Figura 2.51: Revisión de procesos anidados en consola.

33
Si ahora hacemos la búsqueda reversa y ejecutamos el comando [ r o o t @ l o c a l h o s t ~ ] #
t a i l - 0 f / v a r / l o g / h t t p d / a c c e s s _ l o g & podremos observar que se encuentra en
background ese proceso

Figura 2.52: Revisión de procesos de manera reversa en consola

Ahora si ejecutamos el comando [ r o o t @ l oc a l h o s t ~ ] # p s a xf | g r e p - i t a i l

podremos ver el proceso

Figura 2.53: Revisión de procesos de manera reversa en consola

Si ahora si salimos de la consola mediante el comando exit o Ctrl + d buscamos el mismo proceso
y debería de haber desaparecido.

34
 Figura 2.54: Ejecución de bash anidado en consola

Como se aprecia en la imagen hemos generado un bash anidado invocamos un proceso y como
vemos el proceso a desaparecido, ¿por que sucede esto?, sencillo esto sucede porque se murio el
proceso padre de esos procesos hijos. Al momento que se realizó un exit todos los procesos que
dependen del proceso bash mueren.

Práctica 7. Desacoplar procesos

Para evitar que los procesos mueran al momento que el proceso padre muere se debe utilizar el
comando disown que tiene un significado como de desheredar

35
 Figura 2.55: Ejecución del comando disown en consola.

Figura 2.56: Revisión del estado del trabajo en consola

Revisamos el trabajo mediante el comando: [ r o o t@ l o ca l h o s t ~ ] # j o b s

36
 Figura 2.57: Revisión del estado del trabajo en consola

Luego de haber realizado los pasos anteriores procedemos a ejecutar el comando disown el mismo
que me permitirá mantener el proceso hijo aun habiendo muerto el proceso padre
[root@localhost ~]# disown

Figura 2.58: Ejecución del comando disown en consola

Como podemos apreciar la ejecución del comando d i so w n no muestra ninguna salida, no toma
estándar input no emite estándar output puede llegar a emitir estándar error pero con que nos
haya devuelto la consola con el cursos es suficiente, para comprobar lo acontecido escribimos
sobre la consola Ctrl + d o exit

Figura 2.59: Resultado del comando disown en consola

37
 Figura 2.60: Resultado del comando ps axf | grep –i tail en consola

Como podemos apreciar en la figura 2.60 el proceso está corriendo en background, esto es
fundamental para la administración de servidores y dejar corriendo ciertos servicios que son
importantes sin que este asociado a la consola y que cuando se desee salir de la consola no
solamente se termine el proceso de la consola sino que también se terminen todos los procesos
hijos, el problema de este comando es que cualquier string de datos emitidos hacia estándar
output estándar error, no se lo va capturar excepto que se lo especifique, lo que se puede hacer
es una redirección para que no lo envié a null, como realizamos eso de la siguiente manera.
Pasos necesarios para realizar el ejercicio
1. [root@localhost ~]# su –
2 . [ r o o t @ l o c a l h o s t ~] # ta i l - 0 f / v a r / lo g /h tt p d / ac c e s s _ l o g
|grep -i access_log &
3. [root@localhost ~]# ta i l - 0f /v a r / lo g / ht t p d / ac c e s s _ lo g >
./ApacheReal &
4. [root@localhost ~]# d i so w n
5. [root@localhost ~]# p s f a x |g r e p - i a cc e s s _l o g
6. [root@localhost ~]# ls ApacheReal

38
 Figura 2.61: Resultado de la ejecución de los comandos anteriores pasó a paso 1, 2, 3, 4, 5, 6 en consola

Práctica 8. Método de prevención de ejecución de proceso mediante el comando disown

Ahora para comprobar que el proceso sigue corriendo debemos de salir de la session mediante el
comando exit e invocar nuevamente el proceso mediante el comando [ r o ot @ l oc a l h os t ~ ] #
ps fax |grep -i access_log

Figura 2.62: Resultado de la ejecución del comando ps fax |grep -i access_log en consola

Podemos listar el fichero mediante el comando:

[ r o o t @ l o c a l h o s t ~ ] # l s - l A p a c h e Re al

39
 Figura 2.63: Resultado de listar el fichero ApacheReal consola

Como podemos comprobar se ha guardado el log en el fichero ApacheReal, hora especifica que se
realizó el proceso.

Figura 2.64: Resultado de listar el fichero ApacheReal consola

Para comprobar ejecutamos el comando telnet en consola y revisamos nuevamente la fecha de

modificación

40
 Figura 2.65: Resultado general de la ejecución del comando telnet y revisión del fichero ApacheReal consola

Procedemos a revisar la actualización mediante el comando c a t A pa c h eR e a l y de echo

podemos observar que si existe una modificación (mirar la fecha de modificación may 29 23:03)

41
 Figura 2.66: Resultado general de la ejecución del comando telnet y revisión del fichero ApacheReal consola

Si deseamos comprobar la misma instrucción del evento, ejecutar el comando tail -f ApacheReal
[ r o o t @ l o c a l h o s t ~ ] # t a i l - f A p a c he Re a l

Figura 2.67: Resultado general de la revisión tail -f ApacheReal.

Procedemos a matar el proceso mediante los comandos kill ID del proceso o killall nombre del
proceso
[ r o o t @ l o c a l h o s t ~ ] # k i l l 1 5 88 6

[root@localhost ~]# killall tail

La figura 2.68 muestra cómo utilizar el comando kill y killall para matar los procesos colgados

42
 Figura 2.68: Resultado de matar el proceso con el comando kill

Planificación de procesos

Recordemos que la multiprogramación busca no tener ocioso al CPU, y siempre tener un proceso
en ejecución para maximizar su utilización, así como la canalización por tiempo compartido, busca
que cada uno de los procesos que están en la memoria, se ejecuten en un núcleo diferente del
CPU, y que este una vez que termine de ejecutar el proceso busque y comience otro proceso de
los que están listos para ejecutarse, intercambiando entre procesos de tal forma que un usuario
puede interactuar con cada programa mientras estos se están ejecutando, y para alcanzar este
objetivo, el planificador de procesos es el encargado de escogerlo de una lista de procesos con
estado disponible (recuerde que el proceso debe estar en el estado listo) para ser ejecutado por un
núcleo del CPU que esté desocupado.

Recuerda que:

Un núcleo del CPU, solo puede ejecutar un proceso a la vez.

La planificación de procesos se refiere a cómo determina el sistema operativo al orden en que irá
cediendo el uso del procesador a los procesos que lo vayan solicitando, y a las políticas que
empleará para que el uso que den a dicho tiempo no sea excesivo respecto al uso esperado del
sistema.
Hay tres tipos principales de planificación:
A largo plazo.- Decide qué procesos serán los siguientes en ser iniciados. Este tipo de planificación
era el más frecuente en los sistemas de lotes (principalmente aquellos con spool) y
multiprogramados en lotes; las decisiones eran tomadas considerando los requisitos pre-
declarados de los procesos y los que el sistema tenía libres al terminar algún otro proceso. La
planificación a largo plazo puede llevarse a cabo con periodicidad de una vez cada varios segundos,
minutos e inclusive horas.
En los sistemas de uso interactivo, casi la totalidad de los que se usan hoy en día, este tipo de
planificación no se efectúa, dado que es típicamente el usuario quien indica expresamente qué
procesos iniciar.

43
 Figura 2.69: Planificador a largo plazo

A mediano plazo.- Decide cuáles procesos es conveniente bloquear en determinado momento,

sea por escasez/saturación de algún recurso (como la memoria primaria) o porque están
realizando alguna solicitud que no puede satisfacerse momentáneamente; se encarga de tomar
decisiones respecto a los procesos conforme entran y salen del estado de bloqueado (esto es,
típicamente, están a la espera de algún evento externo o de la finalización de transferencia de
datos con algún dispositivo).
En algunos textos, al planificador a mediano plazo se le llama agendador (scheduler).

Figura 2.70: Planificador a mediano plazo, o agendador

A corto plazo Decide cómo compartir momento a momento al equipo entre todos los procesos
que requieren de sus recursos, especialmente el procesador. La planificación a corto plazo se lleva
a cabo decenas de veces por segundo (razón por la cual debe ser código muy simple, eficiente y
rápido); es el encargado de planificar los procesos que están listos para ejecución.
El planificador a corto plazo es también frecuentemente denominado despachador (dispatcher).

44
 Figura 2.71: Planificador a corto plazo, o despachador

Interruptor de contexto

Los sistemas operativos de uso general (Microsoft Windows, mac OS X, distribuciones de Linux,
etc.) gestionan un conjunto de interrupciones, las cuales al ser atendidas provocan que un proceso
que se está ejecutando en un núcleo de la CPU, sea suspendido, cambiando su estado, e iniciando
uno nuevo, pero al momento de atender la interrupción el sistema operativo hace un respaldo de
toda la ejecución del proceso vigente (datos y posición del PC), al que llamaremos contexto actual,
para poder restaurarlo y reanudarlo una vez que la interrupción finalizó y fue atendida. Por lo
tanto, en la PCB es almacenado el contexto actual que incluye valores en los registros y la memoria,
haciendo un guardado de los estados actual de la CPU y restauración, para que pueda reanudar el
proceso.
Cambiar el núcleo de la CPU de un proceso a otro proceso requiere realizar un guardado de estado
del proceso actual y una restauración de estado de un proceso diferente, a esta tarea se la conoce
como cambio de contexto (context switch) y se ilustra en la Figura . Cuando se produce un cambio
de contexto, el núcleo guarda el contexto del proceso anterior en su PCB y carga el contexto
guardado del nuevo proceso planificado para ejecutarse. El tiempo del intercambio de contexto es
la sobrecarga pura, porque el sistema no hace ningún trabajo útil mientras se cambia. La velocidad
de conmutación varía de una máquina a otra, dependiendo de la velocidad de memoria, el número
de registros que se deben copiar y la existencia de instrucciones especiales (como una sola
instrucción para cargar o almacenar todos los registros). Una velocidad típica es de varios
microsegundos

45
 Figura 2.72: Diagrama mostrando el intercambio de contexto desde un proceso a otro

Los tiempos de cambio de contexto dependen en gran medida del soporte de hardware. Por
ejemplo, algunos procesadores proporcionan múltiples conjuntos de registros. Un cambio de
contexto aquí simplemente requiere cambiar el puntero al conjunto de registros actual. Por
supuesto, si hay procesos más activos que conjuntos de registros, el sistema recurre a la copia de
datos de registro a la memoria, como antes. Además, cuanto más complejo es el sistema operativo,
mayor es la cantidad de trabajo que debe realizarse durante un cambio de contexto.

Práctica 9. Uso del comando nohup

El comando nohup es la señal que envía el kernel a un proceso cuando tiene que terminar ejemplo.
Debemos de ejecutar una session dentro de la session de consola mediante el comando su –
después de haber ejecutado la consola anidad proceso a ejecutar el comando:
[ r o o t @ l o c a l h o s t ~ ] # n o h u p t a i l - 0f / v ar / l o g /h t t p d/ a c c e ss _ lo g &

Figura2.72: Señales que envía el kernel a un proceso nohup.

Vemos que con la ejecución del comando obtuvimos el identificador del proceso PID, el mismo
que esta resaltado en color negro.
Si procedemos a ejecutar el comando ps axf|grep –i numero de proceso podemos ver que aparece
el proceso ejemplo: [ r o o t @ l o c a l h o s t ~ ]# p s a x f | g re p - i 1 6 7 9 1

46
 Figura 2.73: Señales que envía el kernel a un proceso nohup

Curiosamente podemos identificar que el proceso no aparece con el nohup, lo que quiere decir
que no es un proceso apegado a la consola, por lo que si se realiza un exit y luego se busca el
proceso mediante el comando:
[ r o o t @ l o c a l h o s t ~ ] # p s a x f | g r e p -i 1 6 79 1

En la figura 2.73 vemos que esta el proceso y no tuvo que ejecutar el comando disown, además se
crea un fichero [Link] dentro del directorio donde se ejecutó el comando nohup.

Figura 2.74: Señales que envía el kernel a un proceso nohup

Además, debemos de conocer que si revisamos los ficheros mediante el comando

[ r o o t @ l o c a l h o s t ~ ] # l s – l t r podemos observar que se creó un fichero dentro del
directorio que se ejecutó nohup con el nombre de [Link]

47
 Figura 2.75: Revisión de la creación del fichero [Link]

Para realizar la revisión de la creación del fichero [Link], debemos de ejecutar el comando tail
-0f [Link] y abrimos otra terminal y sobre ella ejecutamos el comando telnet localhost 80
estos serían los resultados.
[ r o o t @ l o c a l h o s t ~ ] # t a i l - 0 f n o h up .o u t

Figura2.76: Revisión de los resultados del fichero [Link]

La figura 2.76 muestra cómo queda el registro el evento

48
 Figura 2.77: Revisión de los resultados del fichero [Link]

A continuación, se indica otra forma de ejecutar un comando que no esté apegado a la consola,
por lo cual al momento de salir de esa consola el proceso no va terminar y se va convertir en un
proceso desheredado.
En los sistemas operativos modernos el huponexit viene desactivado, en sistemas operativos más
antiguos esta opción venia activada para poder comprobar la misma es fundamental ejecutar el
comando shopt.

49
 Figura 2.78: Revisión de los resultados del comando shopt

Para conocer las diferentes señales que envía el kernel a los procesos debemos de ejecutar el
comando trap –l y nos van a aparecer todas las señales que existen disponibles con el nombre y el
código ejemplo.
[root@localhost ~]# trap –l

Figura 2.79: Señales que envía el kernel a los proceso.

Para entender mejor las diferentes señales que envía el kernel a los procesos es fundamental
conocer todas estas señales ejemplo:
Si ejecutamos el comando [ r oo t @ l oc a l h o s t ~]# ta i l - 0f
/ v a r / l o g / h t t p d / a c c e s s _ l o g y luego en la segunda consola buscamos el proceso mediante
el comando [ r o o t @ l o c a l h o s t ~ ] # p s a x f | g r e p - i t a i l identificamos el proceso
ahora procedemos a enviar distintas señales ejemplo:

50
 Figura 2.80: Señales que envía el kernel a los proceso.

Señales de kernel a los procesos

Procedemos a enviar k i l l - 1

Figura 2.81: Señales que envía el kernel a los proceso kill -1.

Podemos observar en la imagen el resultado que muestra la consola 1, la señal que recibió el
proceso es colgar hangup, esta es la señal que recibe el proceso cuando se cierra la consola.

51
 Figura 2.82: Señales que envía el kernel a los proceso kill -2 ID.

Como se aprecia en la imagen la señal que envió el kernel ha el proceso fue de interrupción

Figura 2.83: Señales que envía el kernel a los proceso kill -2 ID (killed).

52
Resultado de haber enviado el comando [ r o ot @l o ca l h o s t ~ ] # k i l l - 9 1 7 3 97 señal
que envía el kernel a un proceso:

Figura 2.84: Señales que envía el kernel a los proceso kill -2 ID (killed).

Resultado de haber enviado la interrupción 15) SIGTERM que es la señal para terminar un proceso
correctamente.

Para profundizar:

Para buscar información en el sistemas operativo lo puedes realizar

mediante el comando a p r op o s s i g n al , y para acceder a una página
del manual puedes ejecutar el comando m a n 7 s i gn a l .

53
Tema 2: Hilos (Threads)

Conceptos de hilos

Hasta este punto, hemos definido al proceso, y se dijo que es un programa que se ejecuta en un
solo núcleo a la vez, pero, en la actualidad los CPUs tienen varios núcleos y estos a su vez varios
hilos. También definimos que, con la multiprogramación y la multitarea, se pueden tener varios
procesos listos en memoria, pero ¿qué tiene que ver todo esto…?
Pues bien, la mayoría de los sistemas operativos modernos han ampliado el concepto de proceso
para permitir que un proceso tenga varios subprocesos a través de los hilos y sean ejecutados
simultáneamente, y por lo tanto, realice más de una tarea a la vez.
Primero, vamos a definir qué es un hilo (thread). Un hilo, también llamado subproceso, es la unidad
más pequeña de la CPU que puede ejecutar un proceso, esta comprende un identificador (Thread
ID), un contador de programa (PC), un conjunto de registros, y una pila, además comparte con los
otros hilos, que pertenecen a un mismo proceso padre, la sección de código, datos y otros recursos
del sistema operativo, como archivos abiertos y señales. Un proceso tradicional tiene un único
subproceso (hilo) de control. Si un proceso tiene varios subprocesos (hilos) de control, puede
realizar más de una tarea a la vez, ver la Figura2.85 donde se ilustra la diferencia entre un proceso
tradicional de un solo subproceso (hilo) (single-threaded) y un proceso multi subprocesos (hilos)
(multithreaded).

Figura2.85: Procesos con un hilo y múltiples hilo

54
Algoritmos de planificación.

Tener una adecuada planificación de la CPU, alivia el problema de decidir qué núcleo de la CPU, se
hará cargo de los procesos que se encuentran en la cola de procesos en estado preparado y en la
actualidad hay muchos algoritmos de planificación (Scheduling Algoritms) de dónde escoger.
Actualmente los CPU modernos cuentan con arquitecturas que traen varios núcleos de
procesamiento y cada núcleo varios hilos, pese a esto, para realizar un estudio más objetivo de
cómo funcionan los algoritmos de planificación nos centraremos en el contexto de los CPU que
sólo tienen un núcleo de procesamiento. Más adelante estudiaremos la planificación del CPU en
el contexto de sistemas con multiprocesador.
Como resumen, un algoritmo de planificación se utiliza para calcular los recursos que consume
otro algoritmo o conjunto de algoritmos (programa) al realizar una determinada tarea. Ejemplo:
Tiempo de finalización y porcentaje de utilización de la CPU
En los algoritmos existen ciertas medidas que se utilizan para evaluarlos:

 Porcentaje de utilización de la CPU por procesos de usuario, como la CPU es el recurso más
caro que tenemos, este necesita ser más utilizado y tratar de salir de los valores reales que
suelen estar entre el 40 y 90 porciento.
 Rendimiento, también llamado throughput, por su nombre en inglés es el número de ráfagas
que se ejecutan por unidad de tiempo. Una ráfaga es definida como el período de tiempo en
que un proceso necesita de la CPU durante su vida, también se lo suele definir como el
número de trabajos por unidad de tiempo.
 Tiempo de espera (E), es el tiempo que una ráfaga ha permanecido en la cola de procesos
con estado de preparado o listo.
 Tiempo de finalización (F), es el tiempo transcurrido desde que una ráfaga comienza a existir
hasta que finaliza. Su fórmula de cálculo es: F = E + t, donde t es el tiempo de la ráfaga en el
CPU.
 Penalización (P), es una medida sin dimensiones que se puede aplicar homogéneamente a
las ráfagas independientemente de su longitud. Su forma de calcular es: P = (E + t) / t = F / t
En general, hay que maximizar los dos primeros parámetros y minimizar los tres últimos. Sin
embargo, estos objetivos son contradictorios, el dedicar más tiempo de CPU a los usuarios se hace
a costa de llamar menos al algoritmo de planificación (menos cambios de proceso), y de
simplificarlo. Esto provoca que la CPU se reparta menos equitativamente entre los procesos, en
detrimento de los últimos tres parámetros.
Dependiendo de los objetivos se elegirá cierto algoritmo. En los sistemas por lotes suele primar el
rendimiento del sistema, mientras que en los sistemas interactivos es preferible minimizar, por
ejemplo, el tiempo de espera.

Planificación por orden de llegada

También llamada planificación de primero en llegar, primero en servirse (FCFS – First-Come, First-
Served Scheduling) por mucho es el algoritmo de planificación de la CPU más simple. Con este

55
esquema, la CPU será asignada al proceso que primero la solicite. La implementación de la
directiva FCFS se gestiona fácilmente con una cola FIFO. Cuando un proceso entra en la cola de
procesos en estado preparado, su PCB se vincula al final de la cola. Entonces, cuando el CPU es
libre, se asigna al proceso que está en el principio de la cola, luego de esto, el proceso en ejecución
es eliminado de la cola. El código del algoritmo de planificación FCFS es fácil de escribir y entender.
En el lado negativo, el tiempo medio de espera con el algoritmo FCFS es a menudo bastante largo.
Considere el siguiente conjunto de procesos que llegan en el momento 0, con la longitud de la
ráfaga de CPU dada en milisegundos:

Proceso Tiempo de ráfaga

P1 24
P2 3
P3 3

Si los procesos llegan en el orden P1, P2, P3 y se sirven en el orden FCFS, obtenemos el resultado
que se muestra en el siguiente gráfico de Gantt.

También los procesos podrían llegar en el orden P2, P3, P1, según el siguiente diagrama de Gantt.

Además, considere el rendimiento de la planificación FCFS en una situación dinámica. Suponiendo

que tenemos un proceso enlazado a la CPU y muchos procesos enlazados a E/S. A medida que los
procesos fluyen alrededor del sistema, puede producirse el siguiente escenario. El proceso
enlazado a la CPU obtendrá y sostendrá la CPU. Durante este tiempo, todos los demás procesos
terminarán su E/S y se moverán a la cola lista, esperando la CPU. Mientras los procesos esperan
en la cola de procesos en estado preparado, los dispositivos de E/S están inactivos. Eventualmente,
el proceso enlazado a la CPU finaliza su ráfaga de CPU y se mueve a un dispositivo de E/S. Todos
los procesos enlazados a E/S, que tienen ráfagas de CPU cortas, se ejecutan rápidamente y vuelven
a las colas de E/S. En este momento, la CPU se encuentra inactiva. A continuación, el proceso
enlazado a la CPU volverá a la cola de procesos en estado preparado y se le asignará la CPU. Una
vez más, todos los procesos de E/S terminan esperando en la cola de procesos en estado preparado
hasta que se realiza el proceso enlazado a la CPU. Hay un efecto de convoy, ya que todos los otros
procesos esperan a que el proceso grande se salga de la CPU. Este efecto da lugar a una utilización
menor de la CPU y de los dispositivos, de lo que podría ser posible si se permitiera que los procesos
más cortos se ejecuten primero.

Tenga en cuenta también que el algoritmo de planificación FCFS no es preventivo. Una vez que a
la CPU se le ha asignado un proceso, ese proceso se mantiene la CPU hasta que la libera, ya sea
terminando su ejecución o porque se realiza una solicitud de E/S. Por lo tanto, el algoritmo FCFS

56
es particularmente problemático para los sistemas interactivos, donde es importante que cada
proceso obtenga una parte de la CPU a intervalos regulares. Sería desastroso permitir que un
proceso mantenga la CPU durante un período prolongado.

Uso de simuladores para algoritmos FCFS

Simulador 1

Figura 2.86: Simulador de planificador de procesos con un hilo y múltiples hilo algoritmo FCFS

Figura 2.87: Selección del tipo de algoritmo FCFS

57
Figura 2.88: Ejecución de los procesos algoritmo FCFS con cola FIFO

Figura 2.89: Ejecución de los procesos y procesos en cola.

58
 Figura 2.90: Ejecución de los procesos y procesos bloqueado, en cola listos, ejecutando.

Simulador 2
Algoritmo de planificación por orden de llegada FCFS

Figura 2.91: Selección del tipo de algoritmo Fcfs.

59
Figura 2.92: Ejecución y modelado del proceso y los hilos a utilizar tipo de algoritmo Fcfs.

60
Simulador 3

Figura 2.93: Simulación masiva de procesos con múltiples hilos y calendarización.

61
Figura 2.94: Simulación masiva de procesos con múltiples hilos y calendarización.

62
Figura 2.95: Espacio total de los procesos en memoria disponible 128Mb a utilizar 114.

63
Figura 2.96: Espacio total de los procesos en memoria disponible 128Mb a utilizar 114.

64
Figura 2.97: Procesos cargador, ejecución con múltiples hilos.

65
Figura 2.98: Procesos cargador, ejecución con múltiples hilos.

66
Planificación con selección del trabajo más corto

Un enfoque diferente para la planificación de la CPU es el algoritmo de programación con selección

del trabajo más corto (SJF – Shortest-Job-First). Este algoritmo asocia con cada proceso la longitud
de la siguiente ráfaga de CPU del proceso. Cuando la CPU está disponible, se asigna al proceso que
tiene la siguiente ráfaga de CPU más pequeña. Si las ráfagas de CPU siguientes de dos procesos
son las mismas, la planificación FCFS es utilizada para romper el empate. Tenga en cuenta que un
término más adecuado para este método de programación sería el algoritmo de la siguiente ráfaga
de CPU más corta, porque la planificación depende de la longitud de la siguiente ráfaga de CPU de
un proceso, en lugar de su longitud total. Usamos el término SJF porque la mayoría de las personas
y libros de texto utilizan este término para referirse a este tipo de planificación.
Como ejemplo de planificación SJF, considere el siguiente conjunto de procesos, con la longitud
de la ráfaga de CPU dada en milisegundos

Proceso Tiempo de ráfaga

P1 6
P2 8
P3 7
P4 3

A través de un diagrama de Gantt, mostraremos como trabaja una planificación SJF.

El algoritmo de planificación SJF es probablemente el óptimo, porque mover un proceso corto

antes de uno largo disminuye el tiempo de espera del proceso corto en mayor medida de lo que
aumenta el tiempo de espera del proceso largo. En consecuencia, la media del tiempo de espera
disminuye.
Aunque el algoritmo SJF es óptimo, no se puede implementar en el nivel de programación de CPU,
ya que no hay manera de conocer la longitud de la ráfaga de CPU siguiente. La planificación SJF a
veces se denomina planificación del proceso con tiempo restante más corto.

67
 Figura 2.99: Algoritmo Planificación con selección del trabajo más corto y velocidad de 1000 fps.

Planificación por turno (Round-Robin)

El algoritmo de planificación por turnos (RR) está diseñado para los sistemas de tiempo
compartido, es similar a la planificación FCFS, pero se añade la preferencia para permitir que el
sistema cambie entre procesos. En estos sistemas se define una pequeña unidad de tiempo,
llamada cantidad de tiempo o sector de tiempo. Se define una pequeña unidad de tiempo, llamada
intervalo de tiempo. Un cuantum (quantum) de tiempo es generalmente de 10 a 100 milisegundos
de longitud. La cola de procesos en estado preparado se trata como una cola circular. El
planificador de la CPU va alrededor de la cola de procesos en estado preparado, asignando la CPU
a cada proceso para un intervalo de tiempo de hasta un quantum de tiempo.
Para implementar la planificación de RR, de nuevo tratamos la cola de procesos en estado
preparado como una cola FIFO de procesos. Los nuevos procesos se agregan al final de la cola de
procesos en estado preparado. El planificador de la CPU selecciona el primer proceso de la cola de
procesos en estado preparado, establece un temporizador para interrumpir después de un
quantum de tiempo, y despacha el proceso.
Durante este proceso, una de dos cosas sucederá. El proceso puede tener una ráfaga de CPU de
menos de un quantum de tiempo. En este caso, el propio proceso liberará la CPU voluntariamente.
El planificador pasará al siguiente proceso en la cola de procesos en estado preparado. Ahora, si la
ráfaga de CPU del proceso actualmente en ejecución es más de un quantum de tiempo, el
temporizador se apagará y causará una interrupción al sistema operativo. Se ejecutará un cambio
de contexto, y el proceso se pondrá al final de la cola de procesos en estado preparado. El
planificador de CPU seleccionará el siguiente proceso en la cola de procesos en estado preparado.
El tiempo promedio de espera bajo la política RR es a menudo largo. Considere el siguiente
conjunto de procesos que llegan en el momento 0, con la longitud de la ráfaga de CPU dado en
milisegundos:

Proceso Tiempo de ráfaga

68
 P1 24
P2 3
P3 3

Si usamos un quantum de tiempo de 4 milisegundos, entonces el proceso P1 obtiene los primeros

4 milisegundos. Puesto que requiere otros 20 milisegundos, se adelanta después del quantum por
primera vez, y la CPU se da al siguiente proceso en la cola, proceso P2. Ahora el proceso P2 no
necesita 4 milisegundos, por lo que se cierra antes de que expire su cuanto de tiempo. Entonces
la CPU se da al siguiente proceso, el proceso P3. Una vez que cada proceso ha recibido un quantum
de tiempo, la CPU se devuelve para procesar P1 durante un tiempo adicional. La programación RR
resultante es la siguiente:

En el algoritmo de planificación RR, no se asigna ningún proceso a la CPU durante más de un

quantum de tiempo en cada turno (a menos que sea el único proceso ejecutable). Si la ráfaga de
CPU de un proceso excede 1 quantum de tiempo, ese proceso se adelanta y se vuelve a poner en
la cola de procesos en estado preparado. El algoritmo de planificación RR es, por lo tanto, un
mecanismo de desalojo.
El rendimiento del algoritmo RR depende en gran medida del tamaño del quantum de tiempo. En
un extremo, si el cuanto de tiempo es extremadamente grande, la política RR es la misma que la
política FCFS. Por el contrario, si el cuanto de tiempo es extremadamente pequeño (digamos, 1
milisegundo), el enfoque RR puede dar lugar a un gran número de cambios de contexto.
Supongamos, por ejemplo, que sólo tenemos un proceso de 10 unidades de tiempo. Si el quantum
es de 12 unidades de tiempo, el proceso termina en menos de 1 tiempo cuántico, sin sobrecarga.
Sin embargo, si el quantum es de 6 unidades de tiempo, el proceso requiere 2 quantos, lo que
resulta en un cambio de contexto. Si el quantum de tiempo es 1 unidad de tiempo, entonces se
producirán nueve cambios de contexto, ralentizando la ejecución del proceso en consecuencia
(Figura ).

Cuanto de Intercambios de
Proceso con un tiempo de 10
tiempo contexto

12 0

6 1

1 9

Figura 2.100: La relación entre el cuanto de tiempo y el intercambio de contextos

Por lo tanto, queremos que el cuándo de tiempo sea más grande con respecto al tiempo de cambio
de contexto. Si el tiempo de cambio de contexto es aproximadamente el 10 por ciento del

69
quantum de tiempo, entonces alrededor del 10 por ciento del tiempo de CPU se gastará en el
cambio de contexto. En la práctica, la mayoría de los sistemas modernos tienen cantidad de tiempo
que oscila entre 10 y 100 milisegundos. El tiempo necesario para un modificador de contexto suele
ser inferior a 10 microsegundos; por lo tanto, el tiempo de cambio de contexto es una pequeña
fracción del quantum de tiempo. El tiempo de respuesta también depende del tamaño del
quantum de tiempo.

Figura 2.101: Algoritmo Planificación por turno (Round-Robin) velocidad de 1000 fps

Figura 2.102: Algoritmo Planificación por turno (Round-Robin).

70
 Figura 2.103: Definición de valor del cuantum para el algoritmo planificación por turno (Round-Robin).

Figura 2.104: Resultado de los procesos y prioridad de llegada planificación por turno (Round-Robin).

Planificación por prioridades

El algoritmo SJF es un caso especial del algoritmo de planificación por prioridades general. Una
prioridad es asociada a cada proceso, y la CPU se asigna al proceso con la prioridad más alta. Los

71
procesos de igual prioridad se planifican en orden FCFS. Un algoritmo SJF es simplemente un
algoritmo de prioridad donde la prioridad (p) es la inversa de la ráfaga de CPU siguiente (predicha).
Cuanto mayor sea la ráfaga de CPU, menor será la prioridad y viceversa.
Tenga en cuenta que discutimos la planificación en términos de alta prioridad y baja prioridad. Las
prioridades se indican generalmente mediante un rango fijo de números, como 0 a 7 o 0 a 4.095.
Sin embargo, no hay un acuerdo general sobre si 0 es la prioridad más alta o más baja. Algunos
sistemas utilizan números bajos para representar una prioridad baja; otros usan números bajos
para la prioridad alta. Esta diferencia puede llevar a confusión. En este texto, suponemos que los
números bajos representan una prioridad alta.
Por ejemplo, considere el siguiente conjunto de procesos, que se supone han llegado en el
momento 0 en el orden P1, P2, …, P5, con la longitud de la ráfaga de CPU dada en milisegundos:

Proceso Tiempo de ráfaga Prioridad

P1 10 3
P2 1 1
P3 2 4
P4 1 5
P5 5 2
A través de un diagrama de Gantt, mostraremos como trabaja una planificación por prioridades.

Las prioridades se pueden definir interna o externamente. Las prioridades definidas internamente
utilizan alguna cantidad medible para calcular la prioridad de un proceso. Por ejemplo, los límites
de tiempo, los requisitos de memoria, el número de archivos abiertos y la relación entre la ráfaga
de E/S media y la ráfaga de CPU media. Las prioridades externas se establecen por criterios fuera
del sistema operativo, como la importancia del proceso, el tipo y la cantidad de fondos que se
pagan por el uso de computadoras, el departamento que patrocina el trabajo y otros factores, a
menudo políticos.
La planificación por prioridades puede ser preventiva o no preventiva. Cuando un proceso llega a
la cola de procesos en estado preparados, su prioridad se compara con la prioridad del proceso
actualmente en ejecución. El algoritmo de planificación de prioridad anterior adelantará la CPU si
la prioridad del proceso recién llegado es mayor que la prioridad del proceso que se está
ejecutando actualmente. Un algoritmo de programación de prioridad no anterior simplemente
pondrá el nuevo proceso en la cabeza de la cola de procesos en estado preparado.
Un problema importante con los algoritmos de planificación por prioridades es el bloqueo
indefinido o la muerte por inanición. Un proceso que está listo para ejecutarse pero que está
esperando para tener acceso a una CPU puede considerarse bloqueado. Un algoritmo de
planificación de prioridades puede dejar algunos procesos de baja prioridad esperando
indefinidamente. En un sistema informático muy cargado, un flujo constante de procesos de
mayor prioridad puede evitar que un proceso de baja prioridad pueda obtener acceso a la CPU.
Generalmente, una de dos cosas sucederá. O bien el proceso eventualmente se ejecutará (a las 2

72
a.m. del domingo, cuando el sistema finalmente se carga ligeramente), o el sistema informático
finalmente se bloqueará y perderá todos los procesos de baja prioridad inacabados. (Se rumorea
que cuando cerraron el IBM 7094 en el MIT en 1973, encontraron un proceso de baja prioridad
que había sido presentado en 1967 y aún no se había ejecutado.)
Una solución al problema del bloqueo indefinido de los procesos de baja prioridad es el
envejecimiento. El envejecimiento implica aumentar gradualmente la prioridad de los procesos
que esperan en el sistema durante mucho tiempo. Por ejemplo, si las prioridades oscilan entre 127
(baja) y 0 (alta), podríamos aumentar periódicamente (digamos, cada segundo) la prioridad de un
proceso de espera en 1. Eventualmente, incluso un proceso con una prioridad inicial de 127 tendría
la prioridad más alta en el sistema y se ejecutaría. De hecho, un proceso de prioridad 127 tardaría
un poco más de 2 minutos en envejecer hasta un proceso de prioridad 0.
Otra opción es combinar la planificación por turnos (RR) y la de prioridades de tal manera que el
sistema ejecute el proceso de mayor prioridad y ejecute procesos con la misma prioridad mediante
la planificación por turnos (RR). Vamos a ilustrar con un ejemplo utilizando el siguiente conjunto
de procesos, con el tiempo de ráfaga en milisegundos:

Proceso Tiempo de ráfaga Prioridad

P1 4 3
P2 5 2
P3 8 2
P4 7 1
P5 3 3

Usando la planificación por prioridades con la planificación por turnos (RR) para procesos con la
misma prioridad, planificaríamos estos procesos de acuerdo con el siguiente diagrama de Gantt
usando un período de tiempo de 2 milisegundos:

En este ejemplo, el proceso P4 tiene la prioridad más alta, por lo que se ejecutará hasta su
finalización. Los procesos P2 y P3 tienen la siguiente prioridad más alta, y se ejecutarán según la
planificación por turnos (RR). Observe que cuando el proceso P2 finaliza en el momento 16, el
proceso P3 es el proceso de mayor prioridad, por lo que se ejecutará hasta que complete la
ejecución. Ahora, sólo quedan los procesos P1 y P5, y como tienen la misma prioridad, se ejecutarán
en según la planificación por turnos (RR) hasta que se completen.

73
 Figura 2.105: Algoritmo de Planificación por prioridades Jfs.

Figura 2.106: Tiempo de llegada de los procesos con su prioridad algoritmo Jfs.

74
Figura 2.107: Tiempo de llegada de los procesos con su prioridad algoritmo Jfs

75
Planificación mediante colas multinivel

Con las planificaciones por prioridades y por turnos (RR), todos los procesos se pueden colocar en
una sola cola y, a continuación, el planificador selecciona el proceso con la prioridad más alta para
ejecutarse. Dependiendo de cómo se administren las colas, puede ser necesaria una búsqueda
O(n) para determinar el proceso de mayor
prioridad. En la práctica, a menudo es más fácil
tener colas independientes para cada prioridad
distinta, y la planificación por prioridades
simplemente planifica el proceso en la cola de
mayor prioridad. Esto se ilustra en la Figura Este
enfoque, es conocido como colas multinivel,
además funciona muy bien cuando la planificación
por prioridades es combinada con la planificación
por turnos (RR): si hay varios procesos en la cola
de mayor prioridad, se ejecutan según el orden de
la planificación por turnos (RR). En la forma más
generalizada de este enfoque, se asigna una
prioridad estáticamente a cada proceso y un Figura 2.108: Colas separadas para cada prioridad
proceso permanece en la misma cola durante el
tiempo de ejecución.
Un algoritmo de planificación mediante colas multinivel también se puede utilizar para particionar
procesos en varias colas independientes basadas en el tipo de proceso (Figura ). Por ejemplo, se
realiza una división común entre los procesos de primer plano (interactivos) y los procesos en
segundo plano (procesamiento por lote). Estos dos tipos de procesos tienen diferentes requisitos
de tiempo de respuesta, por lo que pueden tener diferentes necesidades de planificación. Además,
los procesos en primer plano pueden tener prioridad (definida externamente) sobre los procesos
en segundo plano. Las colas independientes se pueden utilizar para los procesos en primer plano
y en segundo plano, y cada cola puede tener su propio algoritmo de planificación. La cola en primer
plano puede ser planificada por un algoritmo de planificación por turnos (RR), mientras que la cola
en segundo plano está planificada por un algoritmo por orden de llegada (FCFS).

77
 Figura 2.109: Planificación mediante colas multinivel

Además, debe haber una planificación entre las colas, que comúnmente se implementa como
planificación preventiva de prioridad fija. Por ejemplo, la cola en tiempo real puede tener prioridad
absoluta sobre la cola interactiva.
Echemos un vistazo a un ejemplo de un algoritmo de programación de colas multinivel con cuatro
colas, que se enumeran a continuación en orden de prioridad:
Procesos en tiempo real
Procesos del sistema
Procesos interactivos
Procesos por lotes
Cada cola tiene prioridad absoluta sobre las colas de menor prioridad. Ningún proceso en la cola
por lotes, por ejemplo, podría ejecutarse a menos que las colas para procesos en tiempo real,
procesos del sistema y procesos interactivos estuvieran vacías. Si un proceso interactivo entró en
la cola de procesos en estado preparado mientras se ejecutaba un proceso por lotes, el proceso
por lotes se apretaría.
Otra posibilidad es cortar el tiempo entre las colas. Aquí, cada cola obtiene una cierta porción del
tiempo de la CPU, que entonces puede planificar entre sus diversos procesos. Por ejemplo, en el
caso de la cola con procesos en primer plano y segundo plano, la cola en primer plano se puede
disponer del 80 por ciento del tiempo de la CPU para la planificación por turnos (RR) entre sus
procesos, mientras que la cola en segundo plano recibe el 20 por ciento de la CPU para gestionar
sus procesos mediante una planificada por orden de llegada (FCFS).

Planificación mediante colas multinivel retroalimentadas

Normalmente, cuando se utiliza el algoritmo de planificación mediante colas multinivel, los

procesos se asignan permanentemente a una cola cuando entran en el sistema. Si hay colas
independientes para los procesos en primer plano y en segundo plano, por ejemplo, los procesos
no se mueven de una cola a la otra, ya que los procesos no cambian su naturaleza en primer plano

78
o en segundo plano. Esta configuración tiene la ventaja de una baja carga de trabajo de
planificación, pero es inflexible.
Por su parte el algoritmo de planificación mediante colas multinivel retroalimentadas permite que
un proceso se mueva entre colas. La idea es separar los procesos de acuerdo con las características
de sus ráfagas de CPU. Si un proceso utiliza demasiado tiempo de CPU, se moverá a una cola de
menor prioridad. Este esquema deja los procesos interactivos y enlazados a E/S, que normalmente
se caracterizan por ráfagas cortas de CPU, en las colas de mayor prioridad. Además, un proceso
que espera demasiado tiempo en una cola de menor prioridad se puede mover a una cola de
mayor prioridad. Esta forma de envejecimiento previene el bloqueo indefinido.
Por ejemplo, considere una planificación mediante colas multinivel retroalimentadas con tres
colas, numeradas de 0 a 2 (Figura 2.110). El planificador ejecuta primero todos los procesos en la
cola 0. Sólo cuando la cola 0 está vacía ejecutará los procesos en la cola 1. Del mismo modo, los
procesos de la cola 2 se ejecutarán solo si las colas 0 y 1 están vacías. Un proceso que llega para la
cola 1 adelantará un proceso en la cola 2. Un proceso en la cola 1 será a su vez anticipado por un
proceso que llega para la cola 0.
Un proceso de entrada se coloca en la cola 0. Un proceso en la cola 0 recibe un cuanto de tiempo
de 8 milisegundos. Si no termina dentro de este tiempo, se mueve a la cola de la cola 1. Si la cola
0 está vacía, el proceso en la cabecera de la cola 1 recibe un cuanto de 16 milisegundos. Si no
completa, se adelanta y se pone en la cola 2. Los procesos en la cola 2 se ejecutan sobre una
planificación por orden de llegada (FCFS), pero se ejecutan solamente cuando las colas 0 y 1 están
vacías. Para evitar la inanición, un proceso que espera demasiado tiempo en una cola de menor
prioridad se puede mover gradualmente a una cola de mayor prioridad.

Figura 2.110: Colas multinivel retroalimentadas

Este algoritmo de planificación da la prioridad más alta a cualquier proceso con una ráfaga de CPU
de 8 milisegundos o menos. Tal proceso conseguirá rápidamente a la CPU y terminaran su ráfaga
de CPU y se irá a su siguiente ráfaga de E/S. Los procesos que necesitan más de 8 pero menos de
24 milisegundos también se sirven rápidamente, aunque con menor prioridad que los procesos
más cortos. Los procesos largos se van automáticamente a la cola 2 y se sirven según la
planificación por orden de llegada (FCFS) con los ciclos de CPU sobrantes de las colas 0 y 1.
En general, un planificador de colas multinivel retroalimentadas se define mediante los siguientes
parámetros:

79
  El número de colas
 El algoritmo de planificación para cada cola
 El método utilizado para determinar cuándo actualizar un proceso a una cola de prioridad
más alta
 El método utilizado para determinar cuándo a distanciar un proceso a una cola de prioridad
más baja
 El método utilizado para determinar en qué cola entrará un proceso cuando ese proceso
necesite servicio
La definición de un planificador de colas multinivel retroalimentadas lo convierte en el algoritmo
de planificación de la CPU más general. Se puede configurar para que coincida con un sistema
específico que se desee diseñar. Desafortunadamente, también es el algoritmo más complejo, ya
que la definición del mejor planificador requiere algunos medios para seleccionar valores para
todos los parámetros.

Gestión de procesos

Todos los hilos comparten el mismo espacio de direcciones, y así comparten también las mismas
variables globales. Mientras que los procesos pueden ser de distintos usuarios y competir por
recursos entre sí, los hilos de un mismo proceso de usuario cooperan entre si, sin luchar entre sí.
Al igual que los procesos tradicionales, los hilos pueden estar en alguno de los siguientes estados:
En ejecución (Running): cuando el hilo posee la CPU y se encuentra activo.
Bloqueado (Suspend): cuando el hilo se encuentra esperando algún evento o a la espera de que
otro libere el bloqueo por el que se encuentra detenido.
Listo o preparado (Ready): cuando el hilo está preparado para su ejecución, y se encuentra a la
espera de ser elegido por el planificador.
Terminado (Finished): cuando el hilo ha finalizado, pero todavía no ha sido recogido por el hilo
padre, aunque no puede ser planificado nunca más.
Un proceso puede tener uno o más hilos. Los hilos son un mecanismo que permite mejorar el
rendimiento de los sistemas operativos tratando de reducir la sobrecarga producida por el cambio
de contexto entre procesos. Los hilos de un mismo proceso comparten los recursos (memoria,
archivos, etc.), y son la unidad de planificación. Así, un proceso será un objeto estático que posee
un conjunto de recursos para una serie de hilos, que son los objetos dinámicos panificables.

Los hilos en un entorno multihilo tienen las siguientes características que pueden hacerles
deseables en muchas aplicaciones que requieren multitarea:

 Necesitan poca memoria.

80
  Tienen un bajo coste de creación.
 Tienen un bajo coste de sincronización.
 Comparten el mismo espacio de direcciones.
 Pueden progresar independientemente unos de otros.

Planificación del procesador o CPU

La función del planificador del procesador o planificador de CPU (CPU scheduler) es la de

seleccionar entre los procesos que están listos en la cola de espera, y luego verificar si algún CPU
se desocupó y asignan ese núcleo de CPU a uno de procesos de la cola. El planificador de CPU debe
seleccionar un nuevo proceso para la CPU frecuentemente, esto se debe a que un proceso
enlazado a E/S puede ejecutarse solo durante unos pocos milisegundos antes de esperar una
solicitud de E/S, mientras que un proceso enlazado a la CPU requerirá un núcleo de CPU para
duraciones más largas, esto hace que sea poco probable que el planificador conceda el núcleo a
un proceso durante un período prolongado. En su lugar, es probable que esté diseñado para quitar
por la fuerza la CPU de un proceso y planificar otro proceso para ejecutarse. Por lo tanto, el
planificador de CPU se ejecuta al menos una vez cada 100 milisegundos, aunque normalmente con
mucha más frecuencia. Existen algunos sistemas operativos que utilizan otra técnica de
planificación llamada intercambio (swapping), la cual busca eliminar un proceso de la memoria y
la CPU copiándola al disco, para poder asignar ese recurso a otro proceso buscando reducir de esta
manera el grado de multiprogramación, luego este proceso puede ser reintroducido y continuar
su ejecución donde se quedó, copiando el proceso de nuevo a la memoria y eliminándola del disco,
es decir, haciendo un intercambio entre el disco y la memoria, este proceso es recomendable
cuando la memoria física del computador se ha sobre comprometido y debe liberarse.

81
 Herramientas de entornos digitales
Herramientas SO Link de descarga
Ubuntu 20.04 [Link]
Redhat [Link]
Simulador de máquinas virtuales L-W [Link]

82
BIBLIOGRAFÍA

Redhat. (2021, 04 26). RedHat. Retrieved from

[Link]
Serna, M., & Allende, S. (2020). Sistemas operativos: Linux. In J. Sarmiento (Ed.). Universitas.
Silberschatz, A., Galvin, P. B., & Gagne, G. (2018). Operating Systems Concepts (10th ed.). Hoboken:
Wiley.
Stallings, W. (2018). Operating Systems, Internals and Design Princiles (Ninth ed.). Malaysia:
Pearson.
vmware. (2021). vmware. Retrieved 04 26, 2021, from
[Link]
Wikipedia. (2020, 11 15). BootX (Apple). Retrieved from BootX (Apple):
[Link]
Wikipedia. (2020, 11 15). GNU GRUB. Retrieved from GNU GRUB:
[Link]
Wikipedia. (2020, 11 15). iBoot. Retrieved from iBoot: [Link]
Wikipedia. (2020, 11 15). NTLDR. Retrieved from NTLDR: [Link]
Wikipedia. (2020, 11 15). Windows NT 6 startup process. Retrieved from Windows NT 6 startup
process: [Link]

83