Sistema operativo

Pablo Ruiz M´zquiz
u

libro abierto / serie apuntes

Sistemas Operativos
¬¬¬¬0.5.0

Programa 2

¨

¨

¨

©

¦

¦

§

§

§

¦

¦

¨
©

©
¨
©

¨

©
¨
©

©
¨

©

©

¨

Programa 1
¦

¦

§

§

§

¦

¦

¦

§

§

§

P1 inactivo P1 inactivo P1 inactivo P2 inactivo P2 inactivo P2 inactivo

(a) Ejecución secuencial

!

¤
¥

!

¤

!
¢

¢
£

£

¤

¤

¥
¥

¥

¤
¥

!

¡

¡

¢
£

¢
£

¡

¢

¡

¡

¡

£

¡

¡

£
¢

¢
£

¢

¢
¤
¥

!
!

£

£

¥
¤

¤

P1

¥

!

#

P2

¤

!

#

#

#

#

P1

¥

!

#

#

#

P2

Programa 1
#

¡

P1

Tiempo

Programa 2

P2

Tiempo
(b) Ejecución multiprogramada

Un libro libre de Alqua

† lomo para ediciones impresas

ALQ

004.451

SSOO

Sistemas Operativos

http://alqua.org/libredoc/SSOO

Pablo Ruiz M´zquiz
u

pablo@alqua.org

http://alqua.org/people/pablo

Sistemas Operativos
versi´n 0.5.0
o
15 de abril de 2004

alqua,madeincommunity

c
copyleft
Copyright (c) 2004 Pablo Ruiz M´zquiz.
u
This work is licensed under the Creative Commons Attribution-NonCommercial-ShareAlike License. To
view a copy of this license, visit http://creativecommons.org/licenses/by-nc-sa/1.0/ or send a letter to
Creative Commons, 559 Nathan Abbott Way, Stanford, California 94305, USA.
Copyright (c) 2004 Pablo Ruiz M´zquiz.
u
Este trabajo cae bajo las provisiones de la licencia Atribuci´n-No Comercial-Comparte Igual de Creative
o
Commons. Para ver una copia de esta licencia visite http://creativecommons.org/licenses/by-nc-sa/1.0/
o escriba una carta a Creative Commons, 559 Nathan Abbott Way, Stanford, California 94305, USA.

Serie apuntes
´
Area Sistemas operativos
CDU 004.451

Editores
Pablo Ruiz M´zquiz
u

pablo@alqua.org

Notas de producci´n
o
´
Plantilla latex-book-es-b.tex, v. 0.1 (C) Alvaro Tejero Cantero.
compuesto con software libre

´
Indice general

Portada

I

Copyleft

VI

´
Indice general

VII

1. Introducciń a los Sistemas Operativos
o
1.1. Definiciń de Sistema Operativo . . . . . . . . . . . . . . . . . . . . . .
o
1.2. Relaciń con la m´quina subyacente . . . . . . . . . . . . . . . . . . . .
o
a
1.2.1. Componentes b´sicos de la arquitectura Von Neuman . . . . . .
a
1.2.2. Registros del procesador . . . . . . . . . . . . . . . . . . . . . . .
1.2.3. Ejecuciń de instrucciones . . . . . . . . . . . . . . . . . . . . . .
o
1.2.4. Interrupciones . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.3. Funciones y objetivos de los Sistemas Operativos . . . . . . . . . . . . .
1.3.1. El Sistema Operativo como Interfaz Usuario/Computadora . . .
1.3.2. El Sistema OPerativo como administrador de recursos . . . . . .
1.3.3. Facilidad de evoluciń del Sistema Operativo . . . . . . . . . . .
o
1.4. Evoluciń hist´rica de los Sistemas Operativos . . . . . . . . . . . . . .
o
o
1.4.1. Proceso en serie. Primera generaciń (1945-1955) . . . . . . . . .
o
1.4.2. Sistemas sencillos de proceso por lotes. Segunda generaciń (1955o
1965) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.4.3. Multiprogramaciń. Tercera Generaciń (1965-1980) . . . . . . .
o
o
1.4.4. Computadoras personales. Cuarta Generaciń (1980-1990) . . . .
o
2. Gestiń de procesos
o
2.1. Procesos y tareas . . . . . . . . . . . . . . . . . . . . . . . . . .
2.1.1. Divisiń impl´
o
ıcita y expl´
ıcita de tareas . . . . . . . . . .
2.1.2. Tipos de procesos y relaciń entre procesos concurrentes
o
2.1.3. El sistema operativo y los procesos . . . . . . . . . . . .
2.2. Creaciń y terminaciń de procesos . . . . . . . . . . . . . . . .
o
o
2.3. Estados de un proceso . . . . . . . . . . . . . . . . . . . . . . .
2.3.1. Modelo de dos estados . . . . . . . . . . . . . . . . . . .
2.3.2. Modelo de 5 estados . . . . . . . . . . . . . . . . . . . .
2.3.3. Procesos suspendidos . . . . . . . . . . . . . . . . . . . .
2.4. Estructuras de control del sistema operativo . . . . . . . . . . .

.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.
.

1
1
2
2
3
4
5
7
7
9
9
10
10

. 11
. 11
. 13

.
.
.
.
.
.
.
.
.
.

15
15
15
16
17
18
19
19
21
23
27

vii

´
INDICE GENERAL
2.4.1.
2.4.2.
2.4.3.
2.4.4.
2.4.5.

Tablas de memoria, de E/S, de archivos y de procesos . .
Bloque de control de procesos (BCP) . . . . . . . . . . . .
Estados del sistema y listas de procesos . . . . . . . . . .
Conmutaciń de procesos . . . . . . . . . . . . . . . . . .
o
Servicios del sistema operativo para la gestiń de procesos
o

.
.
.
.
.

.
.
.
.
.

.
.
.
.
.

.
.
.
.
.

3. Planificaciń de procesos
o
3.1. Concepto y criterios de planificaciń . . . . . . . . . . . . . . . . . . . .
o
3.1.1. Utilizaciń del procesador: . . . . . . . . . . . . . . . . . . . . .
o
3.1.2. Productividad . . . . . . . . . . . . . . . . . . . . . . . . . . . .
3.1.3. Tiempo de retorno . . . . . . . . . . . . . . . . . . . . . . . . . .
3.1.4. Tiempo de espera . . . . . . . . . . . . . . . . . . . . . . . . . .
3.1.5. Tiempo de respuesta . . . . . . . . . . . . . . . . . . . . . . . . .
3.2. Tipos de planificadores . . . . . . . . . . . . . . . . . . . . . . . . . . . .
3.2.1. Planificador a largo plazo (PLP) . . . . . . . . . . . . . . . . . .
3.2.2. Planificador a corto plazo (PCP) . . . . . . . . . . . . . . . . . .
3.2.3. Planificador a medio plazo (PMP) . . . . . . . . . . . . . . . . .
3.3. Algoritmos de planificaciń . . . . . . . . . . . . . . . . . . . . . . . . .
o
3.3.1. Algoritmo First Come First Serve (FCFS) . . . . . . . . . . . . .
3.3.2. Algoritmo por reparto circular de tiempo (RR, Round-Robin) . .
3.3.3. Planificaciń con expropiaciń basada en prioridades (ED, Evento
o
Driven) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
3.3.4. Planificaciń MLQ (Multiple level queues) . . . . . . . . . . . . .
o
4. Programaciń Concurrente
o
4.1. Multitarea, multiprogramaciń y multiproceso . . . . . . . . . . . . . . .
o
4.2. Principios de concurrencia . . . . . . . . . . . . . . . . . . . . . . . . . .
4.3. Comunicaciń y sincronizaciń de procesos . . . . . . . . . . . . . . . .
o
o
4.3.1. Posibilidades de interacciń de procesos . . . . . . . . . . . . . .
o
4.3.2. Necesidad de sincronizaciń de los procesos: regiń cr´
o
o
ıtica y exclusiń mutua . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
o
4.4. Soluciones software para la exclusiń mutua . . . . . . . . . . . . . . . .
o
4.4.1. Algoritmo de Dekker . . . . . . . . . . . . . . . . . . . . . . . . .
4.4.2. Algoritmo de Peterson . . . . . . . . . . . . . . . . . . . . . . . .
4.4.3. Sem´foros . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
a
4.4.4. Monitores . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
4.4.5. Paso de mensajes . . . . . . . . . . . . . . . . . . . . . . . . . . .
4.4.6. Soluciones hardware para la exclusiń mutua . . . . . . . . . . .
o
5. Interbloqueos
5.1. Principios de interbloqueo . . . . .
5.1.1. Recursos reutilizables . . .
5.1.2. Recursos consumibles . . .
5.1.3. Condiciones de interbloqueo

viii

.
.
.
.

.
.
.
.

.
.
.
.

.
.
.
.

.
.
.
.

.
.
.
.

.
.
.
.

.
.
.
.

.
.
.
.

.
.
.
.

.
.
.
.

.
.
.
.

.
.
.
.

.
.
.
.

.
.
.
.

.
.
.
.

.
.
.
.

.
.
.
.

.
.
.
.

.
.
.
.

.
.
.
.

.
.
.
.
.

27
28
30
31
32

.
.
.
.
.
.
.
.
.
.
.
.
.

35
35
35
35
36
36
36
36
36
37
38
38
39
39

. 42
. 43

.
.
.
.

45
45
45
46
46

.
.
.
.
.
.
.
.

47
49
49
50
56
58
60
63

.
.
.
.

73
73
73
73
74

Sistemas Operativos - 0.5.0

´
INDICE GENERAL
5.2. Prevenciń de interbloqueos . . . . . . . . . . . . . .
o
5.3. Detecciń de interbloqueos . . . . . . . . . . . . . . .
o
5.4. Predicciń de interbloqueo. Algoritmo del banquero
o
5.4.1. Negativa de iniciaciń de procesos . . . . . .
o
5.4.2. Negativa de asignaciń de recursos . . . . . .
o

.
.
.
.
.

.
.
.
.
.

.
.
.
.
.

.
.
.
.
.

.
.
.
.
.

.
.
.
.
.

.
.
.
.
.

.
.
.
.
.

.
.
.
.
.

.
.
.
.
.

.
.
.
.
.

6. Gestiń de memoria
o
6.1. Reubicaciń . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
o
6.2. Asignaciń de memoria con particiones fijas . . . . . . . . . . . . . . . .
o
6.3. Asignaciń de memoria con particiones din´micas . . . . . . . . . . . . .
o
a
6.4. Asignaciń de memoria con paginaciń simple . . . . . . . . . . . . . . .
o
o
6.5. Asignaciń de memoria con segmentaciń simple . . . . . . . . . . . . .
o
o
6.6. Memoria virtual . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
6.6.1. Estructuras Hardware y de control . . . . . . . . . . . . . . . . .
6.6.2. Hiperpaginaciń y cercan´ de referencias . . . . . . . . . . . . .
o
ıa
6.6.3. Memoria virtual con paginaciń y buffer de traducciń adelantada
o
o
(TLB) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
6.6.4. Software del SO para la gestiń de memoria virtual . . . . . . . .
o

.
.
.
.
.

74
75
76
77
78

.
.
.
.
.
.
.
.

81
81
82
84
84
87
88
88
89

. 90
. 90

´
Indice alfab´tico
e

95

Historia

97

Creative Commons Deed

99

Manifiesto de Alqua

101

El proyecto libros abiertos de Alqua

105

Otros documentos libres

109


ix

´
INDICE GENERAL

x


1 Introducciń a los Sistemas Operativos
o

1.1.

Definiciń de Sistema Operativo
o

Un sistema operativo puede ser contemplado como una colecciń organizada de exteno
siones software del hardware, consistentes en rutinas de control que hacen funcionar al
computador y proporcionan un entorno para la ejecuciń de programas. Adem´s, estos
o
a
programas utilizan las facilidades proporcionadas por el sistema operativo para obtener
acceso a recursos del sistema inform´tico como el procesador, archivos y dispositivos
a
de entrada/salida (E/S). De esta forma, el SO constituye la base sobre la cual pueden
escribirse los programas de aplicaciń, los cuales invocarń sus servicios por medio de
o
a
llamadas al sistema. Por otro lado, los usuarios pueden interactuar directamente con el
SO a trav´s de ´rdenes concretas. En cualquier caso, el SO actá como interfaz entre
e
o
u
los usuarios/aplicaciones y el hardware de un sistema inform´tico.
a
El rango y la extensiń de los servicios proporcionados por un SO dependen de varios
o
factores. As´ las funciones visibles al usuario estń en gran medida determinadas por la
ı,
a
necesidades y caracter´
ısticas del entorno objetivo que el SO est´ destinado a soportar. Por
a
ejemplo, un SO destinado al desarrollo de programas en un entorno interactivo puede
tener un conjunto bastante diferente de llamadas y ´rdenes que un sistema operativo
o
diseãdo para soporte en tiempo de ejecuciń a una aplicaciń de tiempo real dedicada,
n
o
o
tal como el control del motor de un coche, el control del reactor de una central nuclear
o el sistema de actualizaciones derivado de las operaciones de un cajero autom´tico de
a
una entidad bancaria.
Internamente, un SO actá como gestor de los recursos del sistema inform´tico tales
u
a
como el procesador, la memoria, los archivos y los dispositivos de E/S. En esa funciń,
o
el SO mantiene actualizada la informaciń relativa al estado de sistemas que soportan
o
la ejecuciń concurrente de programas, el SO resuelve las peticiones conflictivas de reo
cursos de manera que preserve la integridad del sistema y al hacerlo intenta optimizar
el rendimiento final.
En general, el SO presenta al usuario el equivalente de una m´quina virtual que sea
a
m´s fćil de utilizar que la m´quina subyacente y uno de sus objetivos primarios es increa a
a
mentar la productividad de los recursos que ofrece al sistema mediante una planificaciń
o
lo m´s ´ptima posible de ellos.
a o

1

o

1.2.

Relaciń con la m´quina subyacente
o
a

1.2.1.

Componentes b´sicos de la arquitectura Von Neuman
a

A un nivel muy alto, un sistema inform´tico que implemente la arquitectura Von
a
Neuman cl´sica consta de 3 componentes b´sicos: memoria principal, unidad central
a
a
de proceso y dispositivos de entrada/salida. La unidad central de proceso, a su ves,
est´ constituida por la unidad aritm´tico-l´gica, la unidad de control y un conjunto
a
e
o
de registros. Los componentes b´sicos mencionados se encuentran interconectados para
a
llevar a cabo la funciń principal del computador, que consiste en la ejecuciń de las
o
o
sentencias que forman los procesos. As´ pues, se tienen cuatro elementos estructurales
ı
principales.
Memoria principal: Comńmente conocida como memoria RAM. En ella se enconu
trar´ el programa en c´digo m´quina a ejecutar, los datos de entrada y los resultaa
o
a
dos. La memoria est´ formada por un conjunto de celdas idńticas que pueden ser
a
e
accedidas de forma aleatoria mediante los distintos registros de direccionamiento.
Esta memoria es normalmente vol´til y tambiń se conoce como memoria real.
a
e
La unidad aritm´tico-l´gica permite efectuar un conjunto de opoeraciones aritm´tie
o
e
cas y l´gicas de los datos. Estos datos, que pueden proceder de memoria principal o
o
ser el resultado de operaciones previas, se almacenarń en los registros de entrada
a
de que esta unidad dispone. El resultado de la operaciń, as´ como la informao
ı
ciń relativa al estado de terminaciń de la misma, quedarń almacenados en los
o
o
a
correspondientes registros.
La unidad de control es la que se encarga de hacer funcionar al conjunto, para lo
cual lleva a cabo las siguientes funciones:
• Lee de memoria las instrucciones m´quina que forman el programa.
a
• Interpreta cada instrucciń le´
o
ıda.
• Lee los datos de memoria referenciados por la instrucciń.
o
• Ejecuta la instrucciń.
o
• Almacena el resultado de cada instrucciń.
o
Finalmente, la unidad de Entrada/Salida se encarga de realizar la transferencia de
informaciń entre la memoria (o los registros) y los perif´ricos. La E/S se puede
o
e
efectuar bajo el gobierno de la unidad de control (E/S programada) o de forma independiente (DMA). El transporte de datos se realiza, pues, entre el computador
y su entorno exterior. Dicho entorno consta de una gran variedad de dispositivos externos que incluye a los dispositivos de memoria secundaria, los equipos de
comunicaciń y los terminales.
o
Adem´s de los descritos anteriormente, los sistemas inform´ticos disponene de un cona
a
junto de elementos de interconexiń (buses de datos). Estos elementos estń constituidos
o
a

2


1.2 Relaciń con la m´quina subyacente
o
a
por mecanismos que permiten la comunicaciń entre los componentes que conforman el
o
sistema inform´tico, es decir, su funciń es la de interconectar procesadores, memoria
a
o
principal y m´dulos de E/S.
o

1.2.2.

Registros del procesador

Dentro del procesador hay un conjunto de registros que ofrecen un nivel de memoria
que es m´s r´pido y pequeõ que la memoria principal. Los registros del procesador
a a
n
pueden clasificarse de la siguiente forma:
Registros visibles de usuario: Un registro visible al usuario es aqu´l que puede ser
e
referenciado por medio de lenguaje m´quina que ejecuta el procesador, siendo, por
a
lo general, accesible a todos los programas, tanto de aplicaciń como de sistema.
o
Un programador de lenguaje de m´quina o ensamblador puede minimizar las refea
rencias a memoria principal mediante un uso ´ptimo de estos registros. Los tipos
o
de registro normalmente disponibles son: registros de datos, registros de direcciń
o
y registros de c´digos de condiciń.
o
o
• Los registros de datos pueden ser asignados por el programador a diversas
funciones. En muchos casos, son de prop´sito general y pueden ser empleados
o
por instrucciones que lleven a cabo cualquier tipo de operaciń sobre un dao
to determinado. Sin embargo, suelen establecerse ciertas restricciones como
dedicar algunos registros para operaciones en coma flotante.
• Los registros de direcciń guardan direcciones de memoria principal que pueo
den contener datos, instrucciones o parte de una direcciń efectiva utilizada
o
para calcularla. Como ejemplo de registros de direcciń podemos incluir los
o
siguientes:
◦ Registro ´
ındice: Se utiliza en el direccionamiento indexado que consiste
en sumar un ´
ındice a un valor base para obtener la direcciń efectiva.
o
◦ Puntero de segmento: Cuando se utiliza direccionamiento segmentado la
memoria se divide en segmentos, que son bloques de palabras de tamaõ
n
variable. Una referencia a memoria consta de un segmento particular y
un desplazamiento dentro del segmento.
◦ Puntero de pila: Si existe un direccionamiento de pila visible para los
usuarios, la pila estar´, por lo general, en memoria principal, existiendo
a
un registro dedicado a seãlar la cima de la pila, para poder sacar (pop)
n
e introducir (push) elementos en ella.
• Una ultima categor´ de registros que son, al menos, parcialmente visibles
´
ıa
para los usuarios, son aqu´llos que contienen c´digos de condiciń (tambiń
e
o
o
e
denominados indicadores o flags). Los c´digos de condiciń son bits activados
o
o
por el hardware como resultado de determinadas operaciones. Por ejemplo,
una operaciń aritm´tica puede producir un resultado positivo, negativo, cero,
o
e
con acarreo o con desbordamiento, lo que se reflejar´ en el correspondiente bit
a


3

o
o flag de control y que puede consultarse posteriormente, por ejemplo, como
parte de una operaciń de salto condicional. Es importante tener en cuenta que
o
los c´digos de condiciń pueden ser consultados por las aplicaciones de usuario
o
o
pero no modificados por ´stas. Los bits de c´digo de condiciń se sgrupan en
e
o
o
uno o m´s registros que forman parte de los determinados registros o palabras
a
de control que veremos a continuaciń.
o
En algunas m´quinas, una llamadaa un procedimiento o subrutina provocar´ que
a
a
los registros visibles de usuario se salven autom´ticamente, para luego restaurarlos
a
y continuar con la ejecuciń normal. Este proceso de salvar y restaurar lo lleva a
o
cabo el procesador como parte de las instrucciones de llamada y retorno. Esto permite que cada procedimiento pueda utilizar los registros de forma independiente.
En otras m´quinas, sin embargo, es responsabilidad del programador salvar los rea
gistros que considere relevantes antes de efectuar una llamada a un procedimiento.
Los registros de control y estado son utilizados por el procesador para el control de
las operaciones o por rutinas privilegiadas del sistema operativo para controlar la
ejecuciń de los programas. En la mayor´ de las m´quinas, la mayor parte de estos
o
ıa
a
registros no son visibles para los usuarios. Adem´s de los registros MAR, MBR,
a
IOAR, IOBR, que se utilizan en funciones de direccionamiento e intercambio de
datos entre la unidad procesadora y la memoria principal y los dispositivos de
E/S, la unidad de control tiene asociados una serie de registros, entre los que cabe
destacar el contador de programa (PC, program counter ), que indica la direcciń
o
de la siguiente instrucciń m´quina a ejecutar, el puntero de pila (SP, stack poino
a
ter ), que sirve para manejar la pila del sistema en memoria principal, el registro
de instrucciń (RI) que permite almacenar la instrucciń m´quina a ejecutar, y el
o
o
a
registro de estado (SR) o palabra de estado del programa (PSW, program status
word ) que almacena junto con el contador de programa (PC) diversa informaciń
o
producida por la ultima instrucciń del programa ejecutada (bits de estado aritm´´
o
e
tico) e informaciń sobre la forma en que ha de comportarse la computadora (bits
o
de nivel de ejecuciń que determinan el modo en que la computadora ejecuta las
o
instrucciones, usuario o sistema o supervisor, y bits de control de interrupciones
que establecen las instrucciones que se pueden aceptar).

1.2.3.

Ejecuciń de instrucciones
o

La tarea b´sica que realiza un computador es la ejecuciń de instrucciones. El punto
a
o
de vista m´s sencillo es considerar que el procesamiento de instrucciones consiste en
a
una sencuencia sencilla que se repite a alta velocidad (cientos de millones de veces por
segundo). Esta secuencia consiste en 3 pasos: lectura de memoria de la instrucciń mó
a
quina apuntada por el PC, incremento del contador del programa - para que apunte a
la siguiente instrucciń m´quina - y ejecuciń de la instrucciń.
o
a
o
o
Esta secuencia tiene 2 prioridades fundamentales: es lineal, es decir, ejecuta de forma
consecutiva las instrucciones que estń en direcciones consecutivas, y forma un bucle
a

4


1.2 Relaciń con la m´quina subyacente
o
a
infinito. Esto significa que la unidad de control de la computadora est´ continua e inina
terrumpidamente realizando esta secuencia.
Podemos decir, por tanto, que lo unico que sabe hacer la computadora es repetir a
´
gran velocidad esta secuencia. Esto quiere decir, que para que realice algo util, se ha de
´
tener cargados en memoria un programa m´quina con sus datos y hemos de conseguir
a
que el contador de program apunte a la instrucciń m´quina inicial del programa.
o
a
El esquema de ejecuciń lineal es muy limitado, por lo que se aãden unos mecanismos
o
n
que permiten alterar esta ejecuciń lineal. En esencia, todos ellos se basan en algo muy
o
simple; modifican el contenido del programa, con lo que se consigue que se salte o bifurque
a otro segmento del programa o a otro programa (que, l´gicamente, tambiń ha de residir
o
e
en memoria). Los tres mecanismos b´sicos de ruptura de secuencia son los siguientes.
a
Las instrucciones m´quina de salto o bifurcaciń, que permiten que el programa
a
o
rompa su secuencia lineal de ejecuciń pasando a otro fragmento de s´ mismo.
o
ı
Las interrupciones externas o internas, que hacen que la unidad de control modifique el valor del contador de programa saltando a otro programa.
La instrucciń de m´quina“TRAP”, que produce un efecto similar a la interrupciń,
o
a
o
haciendo que se salte a otro programa.
Si desde el punto de vista de la programaciń son especialmente interesantes las instruco
ciones de salto, desde el punto de vista de los SSOO son mucho m´s importantes las
a
interrupciones y las interrupciones de TRAP. Por tanto, centraremos nuestro inter´s en
e
resaltar los aspectos fundamentales de estos dos mecanismos.

1.2.4.

Interrupciones

Casi todos los computadores tienen un mecanismo mediante el cual otros m´dulos
o
(E/S, memoria) pueden interrumpir la ejecuciń normal del procesador. Las interrupcioo
nes aparecen, principalmente, como una v´ para mejorar la eficiencia del procesamiento
ıa
debido a que la mayor´ de los dispositivos externos son mucho m´s lentos que el proceıa
a
sador.
Con las interrupciones, el procesador se puede dedicar a la ejecuciń de otras instruco
ciones mientras una operaciń de E/S est´ en proceso. Cuando el dispositivo de E/S
o
a
est´ disponible, es decir, cuando est´ preparado para aceptar m´s datos del procesador,
e
e
a
el m´dulo de E/S de dicho dispositivo enviar´ una seãl de solicitud de interrupciń al
o
a
n
o
procesador. El procesador responde suspendiendo la operaciń del programa en curso y
o
saltando a un programa que da servicio al dispositivo de E/S en particular, conocido como rutina de tratamiento de interrupciones (Interrupt handler), reanudando la ejecuciń
o
original despu´s de haber atendido al dispositivo.
e
Desde el punto de vista del programa de usuario una interrupciń es solamente eso:
o
una interrupciń de la secuencia normal de ejecuciń. Cuando el tratamiento de la inteo
o
rrupciń termina, la ejecuciń continá. El programa no tiene que disponer de ningń
o
o
u
u
c´digo especial para dar cabida a las interrupciones; el procesador y el sistema operativo
o


5

o
son los responsables de suspender el pograma de usuario y de reanudarlo despu´s en el
e
mismo punto.
Para dar cabida a las interrupciones, se aãde un ciclo de interrupciń al ciclo de
n
o
instrucciń. En el ciclo de interrupciń el procesador comprueba si ha ocurrido alguna
o
o
interrupciń, lo que se indicar´ con la presencia de alguna seãl de interrupciń. Si no hay
o
a
n
o
interrupciones pendientes, el procesador sigue con el ciclo de lectura y trae la pr´xima
o
instrucciń del programa en curso. Si hay una interrupciń pendiente, el programador
o
o
suspende la ejecuciń del programa en curso y ejecuta una rutina de tratamiento de
o
interrupciń. Esta rutina, generalmente, forma parte del sistema operativo, determina la
o
naturaleza de la interrupciń y realiza cuantas acciones sean necesarias. Una interrupciń
o
o
desencadena una serie de sucesos tanto en el hardware del procesador como en el software.
Estos sucesos pueden secuenciarse de la siguiente forma:
1. El dispositivo emite una seãl de interrupciń al procesador.
n
o
2. El procesador finaliza la ejecuciń de la instrucciń en curso antes de responder a
o
o
la interrupciń.
o
3. El procesador pregunta por la interrupciń comprueba que hay una y env´ una
o
ıa
seãl de reconocimiento al dispositivo que gener´ la interrupciń, de forma que
n
o
o
´ste suspende su seãl de interrupciń.
e
n
o
4. El procesador necesita ahora prepararse para transferor el control a la rutina de
interrupciń. Para empezar, hace falta salvar la informaciń necesaria para reao
o
nudar la ejecuciń del programa en curso en el punto de la la interrupciń. La
o
o
m´
ınima informaciń es la palabra de estado del programa (PSW) y la ubicaciń
o
o
de la pr´xima instrucciń a ejecutar.
o
o
5. El procesador carga ahora el contador de programa con la ubicaciń de entrada
o
del programa de tratamiento de interrupciń.
o
6. La rutina de interrupciń suele comenzar salvando el contenido de los registros del
o
procesador porque la rutina puede utilizarlos y se perder´ la informaciń que la
ıa
o
ejecuciń del proceso interrumpido hibiera dejado en ellos.
o
7. La rutina de tratamiento de la interrupciń procesa la interrupciń realizando las
o
o
acciones requeridas para atenderla.
8. Tras completar el tratamiento de la interrupciń, se recuperan de la pila los valores
o
de los registros que se salvaron y se restauran en los correspondientes registros.
9. El paso final es restaurar los valores del la PSW y del contador de programa tambiń
e
a partir de la pila y continuar con la ejecuciń del programa interrumpido. Estas
o
acciones se llevan a cabo como resultado de ejecutar la instrucciń m´quina para
o
a
retorno de interrupciń, RETI, que incluyen la mayor´ de las computadoras en su
o
ıa
lenguaje m´quina.
a

6


1.3 Funciones y objetivos de los Sistemas Operativos
Las computadoras incluyen varias seãles de solicitud de interrupciń, cada una de las
n
o
cuales tiene una determinada prioridad. En caso de activarse al tiempo varias de estas seãles, se tratar´ la de mayor prioridad, quedando las dem´s a la espera de ser
n
a
a
atendidas. Adem´s la computadora incluye un mencanismo de inhibiciń selectiva que
a
o
permite detener todas o determinadas seãles de interrupciń. Las seãles inhibidas no
n
o
n
son atendidas hasta que pasen a estar desinhibidas. La informaciń de inhibiciń de
o
o
las interrupciones suele incluirse en la parte del registro de estado que solamente es
modificable en nivel de nćleo, por lo que su modificaciń queda restringida al sistema
u
o
operativo.
Las interrupciones se pueden generar por diversas causas, que se pueden clasificar de
la siguiente forma:
Excepciones de programa. Hay determinadas causas que hacen que un programa
presente un problema en su ejecuciń, por lo que deber´ generarse una interrupciń,
o
a
o
de forma que el SO trate dicha causa. Ejemplos de errores de este tipo son el
desbordamiento de operaciones matem´ticas, al divisiń entre cero, el intento de
a
o
acceso a una zona de memoria no permitida, etc.
Interrupciones de reloj.
Interrupciones de E/S. Los controladores de los dispositivos de E/S necesitan interrumpir para indicar que han terminado una operaciń o un conjunto de ellas.
o
Excepciones del hardware como la detecciń de un error de paridad en la memoria.
o
Instrucciones de TRAP. Estas instrucciones permiten que un programa genere una
interrupciń y se utilizan fundamentalmente para solicitar los servicios del SO.
o

1.3.

Funciones y objetivos de los Sistemas Operativos

Como ya se ha visto, un sistema operativo actá como interfaz entre la m´quina
u
a
desnuda y los programas de aplicaciones o el propio usuario. por otro lado, el sistema
operativo tambiń se encarga de gestionar los recursos del sistema inform´tico para
e
a
obtener un uso lo m´s ´ptimo posible de ´stos. A continuaciń, trataremos las funciones
a o
e
o
del sistema operativo desde estos dos puntos de vista, as´ como las caracter´
ı
ısticas que
debe presentar para mantener una capacidad de evoluciń adecuada.
o

1.3.1.

El Sistema Operativo como Interfaz Usuario/Computadora

Un sistema operativo debe hacer que la interacciń del usuario o de los programas
o
de aplicaciń con el computador resulte sencilla y fćil y debe construirse de modo que
o
a
permita el desarrollo efectivo, la verificaciń y la introducciń de nuevas funciones en el
o
o
sistema y, a la vez, no interferir en los servicios ya proporcionados.
El Hardware y el Software que se utilizan para proveer al usuario de aplicaciones puede
contemplarse de forma estratificada o jer´rquica. Este usuario final no tiene que preocua
parse de la arquitectura del computador y contempla el sistema inform´tico en t´rminos
a
e


7

o
de aplicaciones. Estas aplicaciones pueden construirse con un lenguaje de programaciń
o
y son desarrolladas por los programadores de aplicaciones.
Si se tuviera que desarrollar un programa de aplicaciń con un conjunto de instruco
ciones totalmente responsables del control del hardware, dicho programa tendr´ una
ıa
tarea abrumadora y compleja. Para facilitar esta tarea, se ofrecen una serie de programas de sistema. Algunos de estos programas implementan funciones muy utilizadas que
ayudan a la creaciń de aplicaciones de usuario, la gestiń de archivos y el control de los
o
o
dispositivos de E/S. El programa de sistema m´s importante es el sistema operativo.
a
El sistema operativo oculta al programador los detalles del hardware y le proporciona una interfaz c´moda para utilizar el sistema y actá como mediador, ofreciendo al
o
u
programador y a los programas de aplicaciń un conjunto de servicios y utilidades que
o
faciliten su tarea.
De forma resumida el sistema operativo ofrece servicios en las siguientes ´reas:
a
Creaciń de programas: El sistema operativo ofrece una gran variedad de servicios
o
como los editores y depuradores (debuggers), para ayudar al programador en la
creaciń de programas. Normalmente, estos servicios estń en forma de programas
o
a
de utilidad que no forman realmente parte del sistema operativo, pero que son
accesibles a trav´s de ´l.
e
e
Ejecuciń de programas: Para ejecutar un programa es necesario realizar un cierto
o
n´mero de tareas. Las instrucciones y los datos deben cargarse en memoria prinu
cipal, los archivos y los dispositivos de E/S deben inicializarse y deben prepararse
otros recursos. El sistema operativo administra todas estas tareas por el usuario.
Acceso a los dispositivos de E/S: Cada dispositivo de E/S requiere un conjunto
propio y peculiar de instrucciones o seãles de control para su funcionamiento.
n
El sistema operativo, ayudado por los manejadores o drivers de dispositivo tiene
en cuenta estos detalles de forma que el programador pueda pensar en forma de
lecturas y escrituras simples desde o hacia el dispositivo.
Acceso controlado a los archivos: El sistema operativo se ocupa del formato de los
archivos y del medio de almacenamiento. En el caso de sistemas de varios usuarios
trabajando simultńeamente, es el sistema operativo el que brinda los mecanismos
a
para controlar que el acceso a los archivos se lleve a cabo de una forma correcta.
Acceso al sistema: En el caso de un sistema compartido o p´blico, el sistema
u
operativo controla el acceso al sistema como un todo y a los recursos espec´
ıficos
del sistema. Las funciones de acceso deben brindar proteciń a los recursos y a los
o
datos ante usuarios no autorizados y debe resolver conflictos en la propiedad de
los recursos.
Detecciń y respuesta a errores: Cuando un sistema inform´tico est´ en funcioo
a
a
namiento pueden producirse varios errores. El sistema operativo debe dar una
respuesta que elimine la condiciń de error con el menor impacto posible sobre las
o
aplicaciones que estń en ejecuciń.
a
o

8


1.3 Funciones y objetivos de los Sistemas Operativos
Contabilidad: Un sistema operativo debe recoger estad´
ısticas de utilizaciń de los
o
diversos recursos y supervisar par´metros de rendimiento tales como el tiempo de
a
respuesta.

1.3.2.

El Sistema OPerativo como administrador de recursos

Un SO debe perseguir una utilizaciń lo m´s ´ptima y equilibrada posible de los
o
a o
recursos que administra. De esta forma se obtendr´ un alto rendimiento del sistema
a
inform´tico gobernado.
a
El SO es el responsable de la gestiń de los recursos de la m´quina y mediante su
o
a
administraciń tiene el control sobre las funciones b´sicas de la misma. El SO no es nada
o
a
m´s que un programa pero la diferencia clave es su prop´sito. El SO dirige al procesador
a
o
en el empleo de otros recursos del sistema y en el control del tiempo de ejecuciń de los
o
programas de usuario.
Una parte del SO reside en memoria principal. En esta parte est´ el nćleo (kernel )
a
u
que incluye funciones del SO utilizdas con m´s frecuencia aunque, en un momento dado,
a
puede incluir otras partes en uso. El resto de la memoria, que contiene datos y programas
de usuario, es administrada conjuntamente por el SO y por el hardware de control de
memoria. El SO decide cuńdo puede utilizarse un dispositivo de E/S por parte de un
a
programa en ejecuciń y controla el acceso y la utilizaciń de los archivos. El procesador
o
o
es, en s´ mismo, un recurso y es el SO el que debe determinar cuńto tiempo de procesador
ı
a
debe dedicarse a la ejecuciń de un programa usuario en particular. En el caso de sistemas
o
multiprocesador, la decisiń debe tomarse entre todos los procesadores.
o

1.3.3.

Facilidad de evoluciń del Sistema Operativo
o

Un SO importante evolucionar´ en el tiempo por una serie de razones:
a
Actualizaciones del hardware y nuevos tipos de hardware: Las mejoras introducidas
en los componentes hardware del computador deben tener soporte en el sistema
operativo. Un ejemplo es el aprovechamiento del sistema operativo del hardware
de paginaciń que acompaã a la memoria de algunos sistemas inform´ticos.
o
n
a
Nuevos servicios: Como respuesta a nuevas necesidades, el sistema operativo ampliar´ su oferta de servicios para aãdir nuevas medidas y herramientas de control.
a
n
Correcciones: El sistema operativo tiene fallos que se descubrirń con el curso del
a
tiempo y que es necesario corregir.
La necesidad de hacer cambios en un SO de forma regular introduce ciertos requisitos en
el diseõ. Una afirmaciń obvia es que el sistema debe tener una construcciń modular,
n
o
o
con interfaces bien definidas entre los m´dulos y debe estar bien documentado.
o


9

o

1.4.

Evoluciń hist´rica de los Sistemas Operativos
o
o

Para intentar comprender los requisitos b´sicos de un SO y el significado de las caa
racter´
ısticas principales de un sistema operativo contemporńeo, resulta util considerar
a
´
c´mo han evolucionado los sistemas operativos a los largo de los aõs.
o
n

1.4.1.

Proceso en serie. Primera generaciń (1945-1955)
o

En los primeros computadores, de finales de los 40 hasta mediados de los 50, el programa interactuaba directamente con el hardware: no hab´ sistema operativo. La operaciń
ıa
o
con estas m´quinas se efectuaba desde una consola dotada con indicadores luminosos y
a
conmutadores o a trav´s de un teclado hexadecimal. Los programas se arrancan cargane
do el registro contador de programas con la direcciń de la primera instrucciń. Si se
o
o
deten´ el programa por un error, la condiciń de error se indicaba mediante los indicaıa
o
dores luminosos. El programador pod´ examinar los registros relevantes y la memoria
ıa
principal para comprobar el resultado de la ejecuciń o para determinar la causa del
o
error.
El siguiente paso significativo de la evoluciń en el uso de sistemas inform´ticos vino
o
a
con la llegada de dispositivos de E/S tales como tarjetas perforadas y cintas de papel
y con los traductores de lenguajes. Los programas. codificados ahora en un lenguaje
de programaciń, se traducen a un forato ejecutable mediante un programa como un
o
compilador o un int´rprete. Otro programa, llamado cargador, automatiza el proceso de
e
cargar en memoria estos programas en c´digo ejecutable. El usuario coloca un programa
o
y sus datos de entrada en un dispositivo de entrada y el cargador transfiere la informaciń
o
desde el dispositivo a la memoria. Despu´s de transferir el control al programa cargado
e
por medios manuales o autom´ticos, comienza la ejecuciń del mismo. El programa en
a
o
ejecuciń lee sus datos desde el dispositivo de entrada asignado y puede producir ciertos
o
resultados en un dispositivo de salida tal como una impresora o la pantalla.
Estos primeros sistemas presentaban dos problemas principales:
Planificaciń: La mayor´ de las instalaciones empleaban un formulario de reserva
o
ıa
de tiempo de m´quina. Normalmente, un usuario pod´ reservar bloques de tiempo,
a
ıa
m´ltiplos, por ejemplo, de media hora. Si la ejecuciń del programa terminaba antes
u
o
del plazo asignado, el tiempo restante se desperdiciaba. Tambiń pod´ suceder que
e
ıa
el programa no terminara dentro del plazo asignado, con lo que el programadir no
pod´ saber si el programa hab´ terminado satisfactoriamente o no.
ıa
ıa
Tiempo de preparaciń: Un programa aun siendo sencillo requer´ un tiempo de
o
ıa
preparaciń bastante grande ya que en primer lugar se cargaba un compilador
o
y un programa en lenguaje de alto nivel (programa fuente) en la memoria. A
continuaciń, se salvaba el programa ya compilado (programa objeto) y, por ultimo,
o
´
se montaba y cargaba este programa objeto junto con las funciones comunes.
Este modo de trabajo pod´ denominarse proceso en serie porque refleja el hecho de los
ıa
que usuarios ten´ que acceder al computador en serie.
ıan

10


1.4 Evoluciń hist´rica de los Sistemas Operativos
o
o

1.4.2.

Sistemas sencillos de proceso por lotes. Segunda generaciń
o
(1955-1965)

Las primeras m´quinas eran muy caras y, por tanto, era importante maximizar la
a
utilizaciń de las mismas. El tiempo desperdiciado en la planificaciń y la preparaciń
o
o
o
era inaceptable.
Para mejorar el uso, se desarroll´ el concepto de sistema operativo por lotes (batch). El
o
primer sistema operativo por lotes fue desarrollado a mediados de los 50 por la General
Motoros para usar en un IBM 701.
La idea central que est´ detr´s del esquema sencillo de proceso por lotes es el uso de
a
a
un elemento de software conocido como monitor. Con el uso de esta clase de sistema
operativo, los usuarios ya no ten´ acceso directo a la m´quina. En su lugar, el usuario
ıan
a
deb´ entregar los trabajos en tarjetas o en cinta al operador del computador, quien
ıa
agrupaba secuencialmente los trabajos por lotes y ubicaba los lotes enteros en un dispositivo de entrada para su empleo por parte del monitor. Cada programa se constru´
ıa
de modo tal que volviera al monitor al terminar el procesamiento y, en ese momento, el
monitor comenzaba a cargar autom´ticamente el siguiente programa.
a
Para obtener provecho del potencial de utilizaciń de recursos, un lote de trabajos
o
debe ejecutarse autom´ticamente sin intervenciń humana. Para este fin, deben proa
o
porcionarse algunos medios que instruyan al sistema operativo sobre c´mo debe tratar
o
cada trabajo individual. Estas intrucciones son suministradas generalmente por medio
de ´rdenes del sistema operativo incorporadas al flujo de lotes. Las ´rdenes del sistema
o
o
operativo son sentencias escritas en un Lenguaje de Control de Trabajos (JCL, Job Control Language). Entre las ´rdenes t´
o
ıpicas de un JCL se incluyen las marcas de comienzo
y finalizaciń de un trabajo, las ´rdenes para cargar y ejecutar programas y las ´rdenes
o
o
o
que anuncian necesidades de recursos tales como el tiempo esperado de ejecuciń y los
o
requisitos de memoria. Estas ´rdenes se hallan incoporadas al flujo de los trabajos, junto
o
a los programas y a los datos del usuario.
Una parte residente en memoria del SO por lotes, a veces llamado monitor de lotes, lee,
interpreta y ejecuta estas ´rdenes. En respuesta a ellas, los trabajos del lote se ejecutan
o
de uno en uno.

1.4.3.

Multiprogramaciń. Tercera Generaciń (1965-1980)
o
o

Incluso con las mejoras anteriores, el proceso por lotes dedica los recursos del sistema
inform´tico a una unica tarea a la vez.
a
´
En el curso de su ejecucicń, la mayor´ de los programas oscilan entre fases intensivas
o
ıa
de c´lculo y fases intensivas de operaciones de E/S. Esto queda indicado en la figura 1.1
a
donde los periodos de c´lculo intensivo se indican mediante cuadros sombreados y las
a
operaciones de E/S mediante zonas en blanco. El problema es que los dispositivos de
E/S son muy lentos comparados con el procesador. El procesador gasta parte del tiempo
ejecutando hasta que encuentra una instrucciń de E/S. Entonces debe esperar a que
o
concluya la instrucciń de E/S antes de continuar.
o
Esta ineficiencia no es necesaria. Se sabe que hay memoria suficiente para almacenar


11

o
Programa 2

¨

¨

¨

©

¦

¦

§

§

§

¦

¦

¨
©

©
¨
©

¨

©
¨
©

©
¨

©

©

¨

Programa 1
¦

¦

§

§

§

¦

¦

¦

§

§

§

P1 inactivo P1 inactivo P1 inactivo P2 inactivo P2 inactivo P2 inactivo

Tiempo

(a) Ejecución secuencial

#

!

¤
¥

!

¤

!
¢

¢
£

£

¤

¤

¥
¥

¤
¥

£

¡

¢
£

¡

¢

¡

¡

¡

£

¡

¡

£
¢

¢
£

¡

¢

¢
¤
¥

!

¢

£

¥
¤

¤

P1

¥

!
!

£

P2

¥

!

#

P1

¤

!

#

#

#

#

¡

P2

¥

!

#

#

#

P1

Programa 1
Programa 2

P2

Tiempo
(b) Ejecución multiprogramada

Figura 1.1: Ejecuciń secuencial vs multiprogramaciń
o
o

en memoria el sistema operativo (monitor residente) y un programa usuario. Supongamos que hay espacio suficiente para almacenar el sistema operativo y dos programas
de usuario. Ahora, cuando un trabajo necesite esperar por una operaciń de E/S, el
o
procesador puede cambiar a otro trabajo que est´ listo para ser ejecutado. Si ampliae
mos la memoria para almacenar varios programas, podremos conmutar entre todos de
forma que el procesador permanezca ocupado el mayor tiempo posible, evitando as´ el
ı
desperdicio de tiempo que suponen las esperas hasta que se completen las operaciones de
E/S. Este concepto es conocido como multiprogramaciń o multitarea y es el punto
o
central de los sistemas operativos modernos.
Como sugiere la figura 1.1 se pueden lograr ganancias significativas de rendimiento
intercalando la ejecuciń de los programas, o, multiprigramando, que es como se le deo
nomina a este modo de operaciń. Con un solo procesador no es posible la ejecuciń
o
o
paralela de programas, y como m´ximo, s´lo un programa puede tener el control del
a
o
procesador en un instante determinado. El ejemplo presentado en la figura 1.1 (b) consigue un 100 % de utilizaciń del procesador s´lo con dos programas activos. Aunque
o
o
conveniente para ilustrar la idea b´sica en la multiprogramaciń, no se deben esperar
a
o
resultados tan espectaculares en programas reales, ya que las distribuciones de las fases de computaciń y E/S tienden a ser m´s variables. Para aumentar la utilizaciń de
o
a
o
recursos, los sistemas de multiprogramaciń reales permiten generalmente que m´s de
o
a
dos programas compitan por los recursos del sistema al mismo tiempo. El n´mero de
u
programas en competencia activa por los recursos de un sistema inform´tico se denomina
a
grado de multiprogramaciń. En principio, mayores grados de multiprogramaciń deben
o
o
dar lugar a una mayor utilizaciń de recursos.
o
La multiprogramaciń ha sido tradicionalmente empleada para aumentar la utilizaciń
o
o
de los recursos de un sistema inform´tico y para soportar m´ltiples usuarios simultńeaa
u
a
mente activos.

12


1.4 Evoluciń hist´rica de los Sistemas Operativos
o
o

1.4.4.

Computadoras personales. Cuarta Generaciń (1980-1990)
o

Con el desarrollo de la tecnolog´ LCI (Large Scale Integration) de construcciń de
ıa
o
circuitos, que permit´ fabricar chips con miles de transistores en un cent´
ıa
ımetro cuadrado
de silicio, se inicio la era de la computadora personal. En t´rminos de arquitectura, las
e
computadoras personales no eran muy distintas de las minicomputadoras del tipo PDP11, pero en t´rminos de precio s´ eran bastante distintas. Las computadoras personales
e
ı
m´s poderosas reciben el nombre gen´rico de estaciones de trabajo, pero en realidad s´lo
a
e
o
son computadoras personales grandes.
La amplia disponibilidad de poder de c´mputo condujo, junto con un nivel gr´fico
o
a
bastante adecuado, al crecimiento de la industria de producciń de software para las
o
computadoras personales. Gran parte de este software ten´ adem´s, la ventaja de preıa,
a
sentar una gran amiganilidad con el usuario.
Dos sistemas operativos han dominado la escena de las computadoras personales y las
estaciones de trabajo: MS-DOS de Microsoft y UNIX de ATT. MS-DOS tuvo un amplio
uso en el IBM PC y otras m´quinas que incorporaban el microprocesador 8088 de Intel
a
o alguno de sus sucesores. UNIX, su contendiente principal, domin´ las computadoras
o
que no utilizaban microprocesadores de Intel, as´ como las estaciones de trabajo, en
ı
particular las que poseen chips RISC de altas prestaciones.
Un interesante desarrollo que comenz´ a llevarse a cabo a mediados de la dćada
o
e
de los 80 ha sido el crecimiento de las redes de computadoras personales con sistemas
operativos en red y sistemas operativos distribuidos. En un sistema operativo en red, los
usuarios son conscientes de la existencia de varias computadoras y pueden conectarse
con m´quinas remotas. Cada m´quina ejecuta su propio sistema operativo local y tiene
a
a
su propio usuario. Un sistema operativo distribuido, por el contrario, presenta al usuario
un conjunto de computadores independientes como si se tratara de un solo sistema. En
un sistema operativo distribuido los usuarios no deben ser conscientes del lugar donde
su programa va a ejecutarse o la ubicaciń de los archivos a los que desea acceder, esas
o
cuestiones deben ser manejadas autom´ticamente y de forma eficiente por el sistema
a
operativo.


13

o

14


2 Gestiń de procesos
o
2.1.

Procesos y tareas

Proceso una definiciń tradicional de proceso es la de instancia de un programa en
o
ejecuciń. La ejecuciń de tal programa es indicada al SO mediante una acciń u
o
o
o
orden especializada.
El SO responde en ese punto creando un nuevo proceso. En general, esta actividad
consiste en la creaciń e iniciliazaciń de estructuras de datos en el SO para monitorizar
o
o
y controlar el progreso de proceso en cuestiń. Una vez creado, el proceso pasar´ a estar
o
a
activo y competir´ por la utilizaciń de recursos del sistema como el procesador y los
a
o
dispositivos I/O.
Un proceso evoluciona c´
ıclicamente entre per´
ıodos de ejecuciń activa y de espera por
o
la terminaciń de actividades de I/O. Cuando un proceso queda inactivo por especificar
o
una operaciń de I/O y quedar a la espera de que ´sta se complete, el SO puede planificar
o
e
la ejecuciń de otro proceso.
o
Desde este punto de vista, un proceso es una entidad individualmente planificable,
que puede ser asignada al procesador y ejecutada por ´ste. El SO controla, pues, diné
a
micamente la evoluciń de los procesos registrando la informaciń correspondiente a sus
o
o
cambios cuando ´stos se produzcan. Esta informaciń es utilizada por el SO para sus
e
o
labores de planificaciń y gestiń sobre el conjunto de procesos que en un determinado
o
o
momento pueden coexistir en el sistema inform´tico.
a
De esta forma adem´s de la plantilla est´tica constituida por el programa ejecutable
a
a
en que se basa, un proceso posee ciertos atributos que ayudan al SO en su gestiń.
o
Los atributos de un proceso incluyen su estado actual, unidad de planificaciń, derechos
o
de acceso, nivel de prioridad entre otros datos. Desde el punto de vista del usuario, un
proceso no es m´s que la ejecuciń de un conjunto de instrucciones que llevan a cabo una
a
o
determinada tarea, mientras que para el SO es una entidad que atraviesa din´micamente
a
un conjunto de estados y que solicita los recursos del sistema que le son necesarios. De
esta forma, el acceso a tales recursos debe ser planificado de forma que se consiga un
rendimiento en la utilizaciń de los mismos lo m´s ´ptimo posible.
o
a o

2.1.1.

Divisiń impl´
o
ıcita y expl´
ıcita de tareas

Dependiendo del SO y del entorno objetivo de ejecuciń de programas, la divisiń
o
o
de un trabajo en tareas que serń ejecutadas como procesos independientes as´ como la
a
ı
asignaciń inicial de los atributos de esos procesos pueden ser efectuadas o bien por el
o
SO o bien por el desarrollador de la aplicaciń. En otras palabras, lo que constituir´ un
o
a
proceso independiente puede provenir de:

15

o
1. Divisiń impl´
o
ıcita de tareas definida por el sistema.
2. Divisiń expl´
o
ıcita de tareas definida por el desarrollador.
En general, la divisiń impl´
o
ıcita de tareas se aplica en sistemas operativos multitarea
para multiplexar la ejecuciń de una serie de programas y explotar los beneficios de
o
la concurrencia entre una serie de aplicaciones. La divisiń expl´
o
ıcita en tareas permite
mejoras adicionales en el rendimiento al explotar la concurrencia inherente o propia de
una determinada aplicaciń o programa. La divisiń impl´
o
o
ıcita en tareas significa que los
procesos son definidos por el sistema, esta divisiń aparece comńmente en sistemas de
o
u
multiprogramaciń de prop´sito general tales como los sistemas de tiempo compartido.
o
o
En este enfoque cada programa remitido para su ejecuciń es tratado por el SO como
o
un proceso independiente.
El SO asignar´ valores iniciales a lo atributos del proceso tales como la prioridad de
a
planificaciń y los derechos de acceso en el momento de la creaciń del proceso basńdose
o
o
a
en el perfil del usuario y en valores predeterminados del sistema.
La divisiń expl´
o
ıcita significa que los desarrolladores definen expl´
ıcitamente cada proceso y alguno de sus atributos, t´
ıpicamente una unica aplicaciń queda dividida en
´
o
varios procesos relacionados con objeto de mejorar su rendimiento. La divisiń expl´
o
ıcita
se utiliza en situaciones donde se desea elevar la eficiencia o controlar expl´
ıcitamente las
actividades del sistema.
Entre las razones m´s comunes para aplicar la divisiń expl´
a
o
ıcita de tareas se incluyen
1. Ganancia de velocidad: algunas de las tareas independientes en que quede dividida
la aplicaciń podrń ejecutarse de forma concurrente con la consiguiente mejora
o
a
en el tiempo total de ejecuciń de la aplicaciń.
o
o
2. Mejora en el rendimiento de la utilizaciń de dispositivos de I/O con latencia:
o
dedicando tareas expl´
ıcitas a la realizaciń de operaciones I/O, ´stas podrń ser
o
e
a
planificadas por el SO de forma concurrente con tareas de computaciń intensiva
o
con la consiguiente ganancia en el rendimiento.
3. Multiprocesamiento: los procesos independientes que constituyen una aplicaciń
o
pueden ser perfectamente portados para su ejecuciń en un entorno multiprocesao
dor con lo que se conseguir´ paralelismo real.
ıa
4. Computaciń distribuida: de igual forma, cada tarea independiente puede ser asigo
nada a un procesador que forme parte de un sistema distribuido, siendo necesaria
una sincronizaciń con el resto de procesadores que se ocupan de sus respectivas
o
tareas.

2.1.2.

Tipos de procesos y relaciń entre procesos concurrentes
o

En principio, podemos realizar una clasificaciń muy general de los procesos entre
o
procesos de usuario y procesos de sistema. Un proceso de usuario es aquel creado por

16


2.1 Procesos y tareas
el SO como respuesta a una de ejecuciń del usuario o de una aplicaciń que ejecuta a
o
o
instancias de ´ste.
e
Un proceso de sistema es un proceso que forma parte del propio SO y que desempeã
n
alguna de sus labores caracter´
ısticas, como por ejemplo, la elecciń del siguiente proceso
o
a ejecutar o bien la prestaciń de un servicio determinado como el acceso a un recurso de
o
I/O del sistema. Cualquiera que sea la naturaleza de los procesos, ´stos pueden mantener
e
fundamentalmente dos tipos de relaciones: Competiciń y/o Colaboraciń.
o
o
En virtud de la comparticiń de recursos de un solo sistema, todos los procesos concuo
rrentes compiten unos con otros por la asignaciń de los recursos del sistema necesarios
o
para sus operaciones respectivas. Adem´s, una colecciń de procesos relacionados que
a
o
representen colectivamente una sola aplicaciń l´gica, suelen cooperar entre s´ La coopeo o
ı.
raciń es habitual entre los procesos creados como resultado de una divisiń expl´
o
o
ıcita de
tareas. Los procesos cooperativos intercambian datos y seãles de sincronizaciń necesan
o
rios para estructurar su progreso colectivo. Tanto la competiciń como la colaboraciń
o
o
de procesos requiere una cuidada asignaciń y protecciń de los recursos en t´rminos
o
o
e
de aislamiento de los diferentes espacios de direcciones. La cooperaciń depende de la
o
existencia de mecanismos para la utilizaciń controlada de los datos compartidos y el
o
intercambio de seãles de sincronizaciń.
n
o
Los procesos cooperativos comparten t´
ıpicamente algunos recursos y atributos adem´s
a
de interactuar unos con otros. Por esta razń, con frecuencia se agrupan en lo que se
o
denomina una familia de procesos. Aunque dentro de una familia son posibles relaciones
complejas entre sus procesos miembro, la relaciń m´s comńmente soportada por los
o
a
u
sistemas operativos es la relaciń padre-hijo. Esta relaciń se establece cuando el SO
o
o
crea un nuevo proceso a instancias de otro ya existente. Los procesos hijos heredan
generalmente los atributos de sus procesos padres en el momento de su creaciń y tambiń
o
e
pueden compartir recursos con sus procesos hermanos.

2.1.3.

El sistema operativo y los procesos

Todos los SSOO de multiprogramaciń estń construidos en torno al concepto de
o
a
proceso. Los requisitos principales que debe cumplir un SO para con los procesos son los
siguientes:
1. El SO debe intercalar la ejecuciń de procesos para optimizar la utilizaciń del
o
o
procesador ofreciendo a la vez un tiempo de respuesta razonable.
2. El SO debe asignar los recursos del sistema a los procesos en conformidad con una
pol´
ıtica espec´
ıfica que evite situaciones de interbloqueo.
3. El SO podr´ tener que dar soporte a la comunicaciń entre procesos y ofrecer
ıa
o
mecanismos para su creaciń, labores que pueden ser de ayuda en la estructuraciń
o
o
de aplicaciones.


17

o

2.2.

Creaciń y terminaciń de procesos
o
o

Cuando se aãde un proceso a los que ya est´ admisnitrando el SO, hay que construir
n
a
las estructuras de datos que se utilizan para gestionar y controlar el proceso y asignar
el espacio de direcciones que va a utilizar dicho proceso. Estas acciones constituyen la
creaciń de un nuevo proceso.
o
Son cuatro los sucesos comunes que llevan a la creaciń de un proceso.
o
1. Nueva tarea en un sistema de proceso por lotes.
2. Nueva conexiń interactiva.
o
3. Nuevo proceso creado por el SO para dar un servicio.
4. Un proceso generado por otro ya existente.
Por otro lado, en cualquier sistema inform´tico debe existir alguna forma de que un
a
proceso indique su terminaciń. Un trabajo por lotes debe incluir una instrucciń de
o
o
detenciń halt o una llamada expl´
o
ıcita a un servicio del sistema operativo para indicar
su terminaciń, mientras que en una aplicaciń interactiva, ser´ la acciń del usuario la
o
o
a
o
que indique cuńdo termine el proceso.
a
Todas estas acciones provocan al final una peticiń de servicio al SO para terminar el
o
proceso demandante. Adem´s, una serie de errores pueden llevarnos a la terminaciń de
a
o
un proceso. A continuaciń se enumeran algunas de las condiciones m´s habituales de
o
a
terminaciń de procesos:
o
1. Terminaciń normal: Un proceso termina de ejecutar su conjunto de instrucciones
o
y finaliza.
2. Tiempo l´
ımite excedido: El proceso requiere m´s tiempo para completar su ejecua
ciń del que el sistema establece como m´ximo.
o
a
3. No disponibilidad de memoria: Tiene lugar cuando un proceso necesita m´s mea
moria de la que el sistema puede proporcionar.
4. Violaciń de l´
o
ımites: Ocurre cuando un proceso trata de acceder a una posiciń de
o
memoria a la que no puede hacerlo.
5. Error de protecciń: Se produce si un proceso intenta utilizar un recurso o un
o
archivo para el que no tiene permiso o trata de utilizarlo de forma incorrecta.
6. Error aritm´tico: Aparece si el proceso intenta hacer un c´lculo prohibido como
e
a
la divisiń por cero o trata de almacenar un n´mero mayor del que el hardware
o
u
acepta.
7. Superaciń del tiempo m´ximo de espera por un recurso: En este caso, el proceso
o
a
se encuentra a la espera de obtener un recurso o de que tenga lugar un determinado
evento durante un tiempo que alcanza el l´
ımite establecido.

18


2.3 Estados de un proceso
8. Fallo de dispositivo I/O: Se produce por un error en la entrada o la salida tal como
la incapacidad de encontrar un archivo o la ocurrencia de un fallo de lectura o
escritura despu´s de un n´mero m´ximo de intentos.
e
u
a
9. Instrucciń no v´lida: Se produce si un proceso intenta ejecutar una instrucciń
o
a
o
inexistente.
10. Inento de acceso a una instrucciń privilegiada: Se presenta si un proceso intenta
o
utilizar una instrucciń reservada para el SO.
o
11. Mal uso de los datos: Un elemento de dato no est´ inicializado o es de un tipo
a
equivocado para la operaciń que se pretende realizar.
o
12. Intervenciń del operador o del SO: Por alguna razń, el operador o el SO termio
o
na con el proceso. Por ejemplo, si se considera comprometido el rendimiento del
sistema.
13. Finalizaciń del proceso padre: Cuando un proceso padre finaliza el SO puede
o
diseãrse para terminar autom´ticamente con todos sus descendientes.
n
a
14. Solicitud del proceso padre: Un proceso padre tiene normalmente autoridad para
terminar con cualquiera de sus hijos.

2.3.

Estados de un proceso

En cualquier sistema operativo, es b´sico conocer el comportamiento que exhibirń
a
a
los distintos procesos y el conjunto de estados que pueden atravesar.

2.3.1.

Modelo de dos estados

El modelo m´s sencillo que puede construirse tiene en cuenta que un momento dado
a
un proceso puede estar ejecutńdose en el procesador o no. As´ pues, un proceso puede
a
ı
estar en uno de dos estados: Ejecuciń o No ejecuciń (Váse la figura 2.1).
o
o
e

entrada

no ejecución

ejecución

terminar

Figura 2.1: Esquema de un diagrama de dos estados

Cuando el SO crea un nuevo proceso, ´ste entra en el sistema en el estado de No
e
ejecuciń. De este modo, el proceso existe, es conocido por el SO y est´ esperando la
o
a
oportunidad de ejecutarse. En un momento dado, el sistema operativo decide otorgar


19

o
el procesador a un proceso determinado con lo que dicho proceso pasar´ de estado No
a
ejecuciń a Ejecuciń.
o
o
Cada cierto tiempo, el proceso en ejecuciń es interrumpido y el sistema operativo
o
seleccionar´ un nuevo proceso para que tome el control del procesador. El proceso ina
terrumpido pasa del estado de Ejecuciń al de No ejecuciń mientras que el proceso
o
o
elegido realiza la transiciń inversa.
o
Incluso en este modelo tan simple, se aprecian ya algunos de los elementos importantes
en el diseõ de SSOO. Cada proceso debe representarse de forma que el sistema operativo
n
tenga conocimiento de su estado actual y de su posiciń en memoria.
o
Aquellos procesos que no estń en estado de ejecuciń deberń almacenarse en algń
e
o
a
u
tipo de estructura de datos mientras esperan que el sistema operativo les otorgue el
control sobre el procesador. La siguiente figura 2.2 propone una estructura basada en
una cola de procesos.
COLA FIFO
¢

¢
£

¢

¢

¢

¢
£

£

£
¢
£

¡

Procesador

¢

¢

¢

terminar

¢

¢

¢
£

£

¢

¤

¥

¤

¤

¤

¥

¥

¡

¤
¥

¡

¢
¡

¥

¤
¥

¡

£

¥

¡

¡

¤

¥

¡

£

£

¤

¡

¢
¡

£

¤

¡

£

¥

¤
¡

entrada

¤
¥

¤
¥

¥

Figura 2.2: Esquema de un sistema de Cola FIFO

Dicha cola consiste en una lista enlazada de bloques en la que cada uno de estos bloques
representa a un proceso. Cada bloque consistir´ en un puntero a la estrcutura de datos
a
donde el SO guarda toda la informaciń relativa al proceso. El comportamiento del SO en
o
este caso es similar al de un gestor de colas. As´ cada vez que el SO cree un nuevo proceso
ı,
se introducir´ el correspondiente bloque al final de la cola, acciń que tambiń se llevar´
a
o
e
a
a cabo cuando un proceso sea expropiado del procesador en favor de otro o cuando se
bloquee en espera de que se complete una operaciń de E/S. Cuando un proceso termine
o
su ejecuciń, ser´ descartado del sistema. Si todos los procesos estuvieran siempre listos
o
a
para ejecutar, la disciplina de comportamiento de cola presentada ser´ eficaz. El modelo
ıa
de cola sigue un comportamiento FIFO y el procesador opera siguiendo un turno rotatorio
con los procesos disponibles. De esta forma, a cada proceso de la cola se le otorga una
cierta cantidad de tiempo para ejecutar. Si no se presentan bloqueos y transcurrido ´ste
e
volver´ a la cola para optar de nuevo a tener control sobre el procesador. Sin embargo,
a
esta implementaciń no es adecuada debido a que algunos procesos en estado de no
o
ejecuciń estarń listos para ejecutar mientras que otros se encontrarń a la espera de
o
a
a
obtener algń recurso solicitado o a que se complete una operaciń de E/S. As´ pues, el
u
o
ı
SO puede no entregar el procesador al proceso que se encuentre al frente de la cola. Si
´ste est´ bloqueado, tendr´ que recorrer la cola buscando el primer proceso que no lo
e
a
a
est´ y que lleve m´s tiempo en espera.
e
a
Una forma m´s natural de afrontar esta situaciń es dividir el estado de no ejecucuciń
a
o
o
en dos; los estados listo y bloqueado. Adem´s se aãdirń dos nuevos estados al sistema.
a
n
a

20


Estos estados son: nuevo y terminado, que resultan de utilidad para las labores de gestiń
o
de procesos. As´ se dar´ lugar al modelo de 5 estados.
ı
a

2.3.2.

Modelo de 5 estados

En este modelo un proceso puede encontrarse en cualquiera de los siguiente 5 estados.
1. Estado Nuevo: esta estado corresponder´ a procesos que acaban de ser definidos
a
pero que ań no han sido admitidos por el sistema operativo como procesos ejecutau
bles. Para estos procesos se habrń realizado ciertas tareas de gestiń interna como
a
o
la asignaciń de un identificador y la creaciń de algunas estructturas de control.
o
o
La principal motivaciń para la existencia de este estado es la limitaciń por parte
o
o
del SO del n´mero total de procesos activos por razones de rendimiento1 o por las
u
restricciones impuestas por la capacidad de la memoria.
2. Estado Listo o Preparado: En este estado se encontrarń aquellos procesos que
a
dispongan de todos los recursos necesarios para comenzar o proseguir su ejecuciń
o
y se encuentran a la espera de que se les concedael control del procesador.
3. Estado de Ejecuciń: En este estado se encuentra el proceso que tiene el control
o
del procesador. Dado que se considerarń arquitecturas que disponen de un unico
a
´
procesador, en un instante determinado s´lo un proceso puede encontrarse en este
o
estado.
4. Estado Bloqueado: En este estado se encuentran aquellos procesos que carecen de
algń recurso necesario para su ejecuciń siendo este recurso distinto del procesador
u
o
o bien se encuentran a la espera de que tenga lugar un determinado evento.
5. Estado Terminado: A este estado pertenecen aquellos procesos excluidos por el SO
del grupo de procesos ejecutables. Un proceso alcanza este estado cuando llega al
punto normal de terminaciń, cuando se abandona debido a un error irrecuperable
o
o cuando un proceso con la debida autoridad hace que termine su ejecuciń. En este
o
punto, el proceso ya no es susceptible de ser elegido para ejecutarse. Sin embargo,
el SO conserva cierta informaciń asociada con ´l para su posible utilizaciń, bien
o
e
o
por otras aplicaciones como programas de utilidad para el an´lisis de la historia
a
y rendimiento del proceso o bien por parte del SO con fines estad´
ısticos. Una vez
extra´ esta informaciń, el SO ya no necesita mantener m´s datos relativos al
ıda
o
a
proceso y ´stos se borran del sistema.
e
En la figura 2.3 presentamos el diagrama de transiciones entre estados
Transiciń a Nuevo: Se crea un nuevo proceso para ejecutar un programa
o

1

Se puede llegar a perder m´s tiempo en la gestiń del cambio de procesos que en el proceso mismo.
a
o


21

o

pasar a ejecución
Admitir

PREPARADO

EJECUCIÓN

Fin de plazo
NUEVO

ocurrencia
de
suceso

esperar
un
suceso

TERMINADO

BLOQUEO

Figura 2.3: Diagrama de transiciones entre estados. La l´
ınea punteada indica situaciń expcecional.
o

Transiciń Nuevo-Preparado: Esta transiciń tiene lugar cuando el SO est´ preparado
o
o
a
para aceptar o admitir un proceso m´s. Se tendrń en cuenta las restricciones
a
a
derivadas de la capacidad de la memoria y que no haya tantos procesos activos
como para degradar el rendimiento.
Transiciń Preparado-Ejecuciń: Esta transiciń se produce cuando el SO selecciona
o
o
o
un nuevo proceso para ejecutar en funciń de su pol´
o
ıtica de planificaciń.
o
Transiciń Ejecuciń-Preparado: La razń m´s comń para esta transiciń es que el
o
o
o
a
u
o
proceso que est´ en ejecuciń ha alcanzado el tiempo m´ximo permitido de ejea
o
a
cuciń ininterrumpida. Hay otras causas alternativas que no estń implementadas
o
a
en todos los SSOO como la expropiaciń de un proceso en favor de otro m´s prioo
a
ritario. Otra situaciń, muy extraordinaria, que origina esta transiciń es que un
o
o
proceso ceda voluntariamente el control del procesador.
Transiciń Ejecuciń-Bloqueo: Un proceso realiza esta transiciń cuando queda a la
o
o
o
espera por la concesiń de un determinado recurso o por la ocurrencia de un deo
terminado suceso.
Transiciń Bloqueado-Preparado: Tiene lugar si a un proceso bloqueado se le concede
o
el recurso solicitado u ocurre el suceso por el que estaba esperando.
Transiciń Preparado-Terminado: Puede ocurrir si, por ejemplo, un proceso padre deo
cide en un momento determinado finalizar la ejecuciń de sus procesos hijos. Si
o
alguno de dichos procesos se encontraba en estado preparado realizar´ esta trana
siciń. Otra razń puede ser debida a un requisito de memoria que es denegado.
o
o
Transiciń Bloqueado-Terminado: Un proceso hijo puede realizar esta transiciń por la
o
o
misma razń que la anterior. Otra causa puede ser que el proceso supere el tiempo
o
m´ximo de espera por un recurso y el sistema operativo decida entonces terminarlo
a
(es la razń m´s habitual).
o
a

22


Este modelo de 5 estados puede implementarse igualmente mediante estructuras de tipo
cola siguiendo un esquema como el se muestra en la figura 2.4.
Entrada

Cola FIFO
Procesador

Terminar

Fin de Plazo
Ocurrencia de
suceso

Cola de bloqueados
Esperar suceso

Figura 2.4: Diagrama de transiciones entre estados implementada con una cola.

Ahora se dispone de dos colas, una para los procesos en situaciń de preparado y
o
otra para los bloqueados. A medida que se admiten procesos nuevos en el sistema, ´stos
e
se sitán en la cola de preparados. Cuando el SO tiene que escoger un proceso para
u
ejecutar, lo hace sacanado uno de dicha cola. En ausencia de prioridades, la referida cola
puede gestionarse mediante un algoritmo FIFO. Cuando un proceso es expropiado del
procesador, puede ser porque ha terminado su ejecuciń, porque ha excedido el tiempo
o
m´ximo de posesiń del procesador y entonces es devuelto a la cola de preparados
a
o
o porque ha quedado bloqueado a la espera de un determinado suceso con lo que se
introducir´ en la cola de bloquedados. Cuando tiene lugar un determinado suceso,
a
todos los procesos que esperaban por ´l son pasados desde la cola de bloquedados a la
e
de preparados.
Esta ultima medida significa que cuando se produce un suceso, el SO debe recorrer toda
´
la cola de bloqueados buscando aquellos procesos que esperen por el suceso. En un SO
grande puede haber una gran cantidad de procesos en la cola de bloqueados, por tanto,
resultar´ m´s eficiente disponer de un conjunto de colas, una para cada suceso. En tal
a a
caso, cuando se produzca un evento, la lista entera de procesos en la cola correspondiente
a ese suceso podr´ pasarse a estado preparado. Váse la figura 2.5.
a
e
Si la planificaciń de procesos se realiza mediante un esquema basado en prioridades,
o
entonces es conveniente tener un cierto n´mero de colas de procesos listos, una para cada
u
prioridad.

2.3.3.

Procesos suspendidos

Debido a que el procesador es mucho m´s r´pido que los dispositivos de E/S puede
a a
ocurrir que en un momento dado todos los procesos del sistema se encuentren bloqueados
a la espera de que se complete alguna operaciń de E/S. Para solucionar este problema
o
existen dos opciones
1. Amplir la memoria del sistema de forma que sea posible albergar en ella m´s
a


23

o

Entrada

Cola FIFO
Terminar

Procesador
Fin de Plazo
Ocurrencia de
suceso 1

Cola de bloqueados por 1
Esperar suceso 1

Ocurrencia de
suceso 2

Cola de bloqueados por 2
Esperar suceso 2

Ocurrencia de
suceso n

Cola de bloqueados por n
Esperar suceso n

Figura 2.5: Diagrama de transiciones entre estados con varias colas, una para cada proceso.

procesos e incrementar as´ la posibilidad de que alguno de ellos haga uso efectivo
ı
del procesador.
2. La otra soluciń consiste en aplicar una tćnica conocida como intercambio o swao
e
ping. Esta tćnica consiste en que cuando todos los procesos que se encuentran
e
en memoria principal estń bloqueados, el SO puede sacar a uno de ellos de su
a
correspondiente cola y transferirlo a memoria secundaria. El proceso transferido se
dice entonces que queda en estado suspendido. Una vez realizada esta operaciń,
o
el SO est´ en condiciones de traer de nuevo a memoria a un proceso previamente
a
suspendido o bien dar entrada al sistema a un nuevo proceso.
En general, se considera suspendido a un proceso que presenta las caracter´
ısticas siguientes:
1. Un proceso suspendido no est´ disponible de inmediato para su ejecuciń.
a
o
2. Un proceso puede estar esperando o no un suceso. Si lo est´, la condiciń de
a
o
bloqueado es independiente de la condiciń de suspendido y el acontecimiento del
o
suceso bloqueante no lo habilita para la ejecuciń.
o
3. El proceso fue situado en estado suspendido por un agente (el SO o el proceso
padre) con el fin de impedir su ejecuciń.
o
4. El proceso no puede apartarse de estado hasta que llegue la orden expresa para
ello.

24


Si aãdimos este nuevo estado a nuestro diagrama de 5 estados, obtendremos la figura
n
2.6.
pasar a ejecución
Admitir

PREPARADO

EJECUCIÓN

Fin de plazo
NUEVO

ocurrencia
de
suceso

esperar
un
suceso

TERMINADO

BLOQUEO
SUSPENDIDO

Figura 2.6: Diagrama de 5 estados + suspendido

Teniendo en cuenta que un proceso suspendido se encontraba bloqueado a la espera
de que ocurriera un cierto suceso y que dicho suceso puede ocurrir mientras el proceso
permanece en memoria secundaria, ser´ m´s eficiente desdoblar el estado suspendido en
ıa a
dos, uno para las procesos suspendidos que ań esperan el suceso que les bloque´ (estado
u
o
bloqueado y suspendido) y otro para los procesos suspendidos que por haber tenido lugar
se encuentran en situaciń de proseguir su ejecuciń (estado listo y suspendido). Para
o
o
verlo mejor, cons´letese la figura 2.7.
u
Las transiciones que involucran a los nuevos estados son las siguientes:
Transiciń Bloqueado y Suspendido-Preparado y Suspendido: Esta transiciń tiene
o
o
lugar si se ha producido un suceso por el que hab´ sido bloqueado el proceso
ıa
suspendido. Es importante tener en cuenta que esto requiere que est´ accesible
e
para el SO la informaciń relativa a los procesos suspendidos.
o
Transiciń Preparado y Suspendido-Preparado: Cuando no hay procesos preparao
dos en memoria principal el sistema operativo tendr´ que traer de memoria secuna
daria un proceso que pueda continuar su ejecuciń. Adem´s, puede darse el caso de
o
a
que el proceso en estado Preparado y Suspendido tenga una nueva prioridad mayor
que la de los procesos en estado Preparado. En este caso se deber´ decidir entre
a
ejecutar el proceso de mayor prioridad con el coste consiguiente de la operaciń
o
de intercambio si no hay espacio en memoria principal para todos los procesos, o
bien esperar a que haya espacio suficiente en memoria principal para albergar al
proceso suspendido.
Transiciń Preparado-Preparado y Suspendido: Como ve´
o
ıamos en la transiciń
o
anterior, se puede producir un intercambio entre un proceso en estado Preparado


25

o

pasar a ejecución
Admitir

PREPARADO

EJECUCIÓN

Fin de plazo
NUEVO

ocurrencia
de
suceso

esperar
un
suceso

TERMINADO

BLOQUEO

Preparado y
Suspendido

Bloqueado y
Suspendido

Figura 2.7: Diagrama de 5 estados + 2 suspendidos (preparado y suspendido, bloqueado y suspendido)

y Suspendido y otro en estado de Preparado si no hay memoria suficiente para
ambos. Generalmente, el SO prefiere suspender a un proceso bloqueado en vez
de a uno en estado Preparado. Sin embargo, puede ser necesario suspender a un
proceso Preparado si ´sta es la unica forma de liberar un bloque lo suficientemente
e
´
grande de memoria principal. Adem´s, el SO puede escoger suspender un proceso
a
Preparado de m´s baja prioridad en lugar de uno bloqueado de prioridad m´s alta
a
a
si se estima que el proceso bloqueado pronto pasar´ a estado de Preparado.
a
Transiciń Bloqueado y Suspendido-Bloqueado: Si un proceso termina y libera
o
memoria principal y existe adem´s algń proceso en la cola de procesos Bloqueados
a
u
y Suspendidos con mayor prioridad de la de todos los proceso que se encuentran
en la cola de Preparados y Suspendidos, el SO puede entonces traer el proceso
a memoria si tiene razones para suponer que va a ocurrir pronto el suceso que
bloque´ al proceso.
o
Transiciń Ejecuciń-Preparado y Suspendido: Generalmente, un proceso en ejecuo
o
ciń pasa al estado Preparado cuando expira su fracciń de tiempo de procesador,
o
o
sin embargo, si se est´ expulsando al proceso porque hay otro de prioridad mayor
a
en la lista de Bloqueados y Suspendidos que acaba de desbloquearse, entonces el
SO podr´ pasar directamente el proceso en ejecuciń a la cola de Preparados y
ıa
o
Suspendidos, liberando as´ espacio en la memoria principal.
ı
ejemplo 1 proceso de prioridad 1 en estado Bloqueado, 3 procesos de prioridad 2 en
Preparado, 1 proceso en Ejecuciń de prioridad 1 y 1 Preparado de prioridad 3. 1
o

26


2.4 Estructuras de control del sistema operativo
bloqueado y suspendido de prioridad 1. los bloqueados lo dejarń de estar pronto.
a
¿qu´ transiciń tendr´ lugar?
e
o
ıa
Entre las razones m´s habituales para la suspensiń de procesos podemos citar las sia
o
guientes:
1. Intercambio un proceso por otro(s): El SO necesita liberar memoria principal para
cargar un proceso que est´ listo para ejecutarse.
a
2. Suspensiń de un proceso por el SO por sospechar que est´ causando algń tipo
o
a
u
de problema.
3. Solicitud expresa del usuario.
4. Un proceso puede ejecutarse peri´dicamente y puede ser suspendido mientras eso
pera el intervalo de tiempo antes de una nueva ejecuciń.
o
5. Por una peticiń del proceso padre.
o

2.4.

Estructuras de control del sistema operativo

El SO es el controlador de los sucesos que se producen en un sistema inform´tico y es
a
el responsable de planificar y expedir a los procesos para su ejecuciń en el procesador.
o
El SO es quien asigna los recursos a los procesos y el que responde a las solicitudes de
servicios b´sicos realizadas por los programas de usuario, esencialemte se puede considea
rar al SO como una entidad que administra el uso que hacen los procesos de los recursos
del sistema.
A continuaciń se tratarń los elementos que necesita el SO para llevar a cabo sus
o
a
labores de control de procesos y de administraciń de recursos.
o

2.4.1.

Tablas de memoria, de E/S, de archivos y de procesos

Si el SO va a administrar procesos y recursos, entonces tiene que disponer de informaciń sobre el estado actual de cada proceso y de cada recurso. El m´todo universal
o
e
para obtener esta informaciń es sencillo. El sistema operativo construye y mantiene tao
blas de informaciń sobre cada entidad que est´ administrando. Por ejemplo, las tablas
o
a
de memoria se utilizan para mantener el control sobre la memoria principal o real y la
secundaria o virtual.
Las tablas de memoria deberń incluir la siguiente informaciń:
a
o
1. Asignaciń de memoria principal a los procesos.
o
2. Asignaciń de memoria secundaria a los procesos.
o
3. Atributos de protecciń de segmentos de memoria principal o secundaria.
o
4. Informaciń necesaria para la gestiń de la memoria secundaria.
o
o


27

o
Las tablas de E/S son utilizadas por el SO para administrar los dispositivos y los canales
de E/S del sistema inform´tico. En un momento dado, un dispositivo de E/S puede
a
estar disponible o estar asignado a un proceso particular. Si hay una operaciń de E/S
o
en marcha el SO necesita conocer el estado de dicha operaciń y la posiciń de memoria
o
o
principal que se est´ utilizando como origen o destino de la transferencia de E/S.
a
El SO tambiń mantiene un conjunto de tablas de archivos, las cuales ofrecen infore
maciń sobre las propiedades de ´stos. Sobre su posiciń y distribuciń en la memoria
o
e
o
o
secundaria, su estado actual y otros atributos. Gran parte de esta informaciń, sino toda,
o
´
puede ser mantenida y utilizada por un sistema de gestiń de archivos. Este consisitir´
o
a
en un m´dulo del SO bien diferenciado y su labor se ocupar´ de todas las operaciones
o
a
necesarias para la gestiń y tratamiento de los archivos.
o
Un ejemplo de estructura para la ubicaciń de archivos es la conocida como FAT
o
(File Allocation Table)2 . Un ejemplo de sistema de ficheros ser´ el utilizado por el SO
ıa
Windows NT y conocido NTFS (NT Filesystem).
Las tablas de procesos almacenan informaciń relativa al conjunto de procesos aco
tivos presentes en un instante determinado en el sistema. La informaciń t´
o ıpicamente
almacenada para cada proceso y conocida como imagen del proceso en memoria consiste
en:
1. Datos de usuario: Almacena los datos con que trabaja el proceso as´ como la pila
ı
utilizada por ´ste. [espacio de direcciones del proceso]
e
2. Programa de usuario: Contiene el c´digo objeto3 del programa que se va a ejecutar.
o
[espacio de direcciones del proceso]
3. Pila de sistema: Se utiliza para almacenar par´metros y direcciones de retorno.
a
[estructuras del sistema operativo]
4. Bloque de control de proceso: Contiene la informaciń necesaria para que un proceo
so pueda ser gestionado y controlado por el SO. [estructuras del sistema operativo]

2.4.2.

Bloque de control de procesos (BCP)

El SO agrupa toda la informaciń que necesita conocer respecto a un proceso particular
o
en una estructura de datos denominada descriptor de proceso o bloque de control de
proceso (BCP). Cada vez que se crea un proceso, el SO crea uno de estos bloques para
que sirva como descripciń en tiempo de ejecuciń durante toda la vida del proceso
o
o
(Váse figura 2.8). Cuando el proceso termina, su BCP es liberado y devuelto al dep´sito
e
o
de celdas libres del cual se extraen nuevos BCPs.
2

Consiste en una tabla enlazada que hace referencia a los sectores del disco duro asignados a un mismo
fichero. FAT da problemas al fragmentarse frecuentemente lo que provoca un retardo al acceder a esos
datos. Para solucionar este problema existen herramientas de desfragmentaciń. En sistemas UNIX
o
se trata desde el principio m´s eficientemente esta asignaciń y los datos almacenados apenas sufren
a
o
fragmentaciń.
o
3
c´digo que puede ser ejecutado por una determinada arquitectura.
o

28



SO

BCPs

¡

¡

¡

¡

¡

¡

¡

¡

¡

¡

¡

¡

¡

¡

¡

¡

¡

¡

¡

¡

¡

¡

¡

¡

¡

¡

¡

¡

¡

¡

¡

¡

¡

¡

¡

¡

¡

¡

¡

¡

¡

¡

¡

¡

¡

¡

¡

¡

¡

¡

¡

¡

¡

¡

¡

¡

¡

¡

¡

¡

¡

¡

¡

¡

¡

¡

¡

¡

¡

¡

¡

¡

¡

¡

¡

¡

¡
¡

¡

¡

¡

¡
¡

¡

¡

¡

¡

¡

¡

¡

¡

Figura 2.8: Dentro de la memoria asignada al SO tenemos unos bloques reservados para los BCPs
de los procesos.

Un proceso resultar´ conocido para el SO y, por tanto, susceptible de ser elegido para
a
competir por los recursos del sistema s´lo cuando existe un BCP activo asociado a ´l4 .
o
e
El BCP es una estructura de datos5 con campos para registrar los diferentes aspectos de
ejecuciń del proceso as´ como de la utilizaciń de los recursos. La informaciń del BCP
o
ı
o
o
se agrupa generalmente en las siguientes categor´
ıas:
1. Identificaciń del proceso
o
La informaciń correspondiente a la identificaciń del proceso consiste en un cono
o
junto de identificadores que incluyen:
a) El identificador del proceso (PID): Consiste en un n´mero entero asignado
u
por el sistema.
b) El identificador del proceso padre
c) La identificaciń del usuario: Es una cadena de caracteres.
o
2. Informaciń del estado del procesador: La informaciń relativa al estado del miso
o
croprocesador consta de:
a) Registros visibles para el usuario: Son los registros utilizados por el proceso
para almacenar datos de entrada y resultados.
b) Registros de control y estado, entre los cuales de incluyen el contador de programa (PC), los regitros de c´digos de condiciń 6 , los registros con indicadores
o
o
de habilitaciń o inhabilitaciń de interrupciones y el modo de ejecuciń.
o
o
o
4

en el modelo de 5 estados, hab´ un estado llamado Nuevo en donde el SO sab´ que exist´ un nuevo
ıa
ıa
ıa
proceso pero sin BCP ya que ań no era candidato para asignarle recursos.
u
5
El SO tiene bloques de memoria libres preparados para almacenar BCPs.
6
bits que reflejan el resultado de una operaciń aritm´tica (bit de overflow, bit de acarreo, bit de cero,
o
e
etc)


29

o
c) Puntero a la pila del proceso: El proceso utiliza una estructura de pila para
almacenar par´metros y direcciones de retorno de funciones y procedimientos
a
3. Informaciń de control y gestiń del proceso: La informaciń de control y gestiń
o
o
o
o
del proceso incluye:
a) Informaciń de planificaciń y estado: esta informaciń es necesaria para que
o
o
o
el SO lleve a cabo sus funciones de planificaciń. Los elementos t´
o
ıpicos de esta
informaciń son los siguientes
o
1) Estado del proceso (ejecuciń, preparado, etc).
o
2) Prioridad de planificaciń (se utilizarń algoritmos de planificaciń que
o
a
o
usarń esta informaciń).
a
o
3) Informaciń para la planificaciń: ´sta depende del algoritmo de planifio
o e
caciń utilizado.
o
4) Suceso por el que se encuentre esperando el suceso para reanudar su
ejecuciń
o
b) Estructuaciń de datos: Un proceso puede estar enlazado con otros procesos
o
formando una cola, un anillo o alguna otra estructura. Por ejemplo; todos los
procesos que se encuentran en estado preparado con un determinado nivel de
prioridad pueden estar enlazado en una cola. El BCP podr´ contener entonces
a
punteros a otros BCPs para dar soporte a esas estructuras.
c) Comunicaciń entre procesos: en el BCP pueden ubicarse indicadores, seãles
o
n
y mensajes asociados con la comunicaciń entre los procesos independientes.
o
d ) Privilegios de los procesos: A los procesos se les otorgan privilegios en t´rminos
e
de la memoria a la que pueden acceder y los tipos de instrucciones que pueden
ejecutar. Adem´s, tambiń se pueden aplicar privilegios al uso de servicios y
a
e
utilidades del sistema.
e) Gestiń de memoria: Esta secciń incluye punteros a las tablas de p´gina y/o
o
o
a
segmentos que describen la memoria asignada al proceso.
f ) Recursos en propiedad y utilizaciń de los procesos: Se incluyen los recursos
o
controlados por el proceso tales como los ficheros abiertos por ´ste. Tambiń
e
e
se suele incluir un hist´rico de la utilizaciń del procesador o de otro recurso.
o
o
Esta informaciń puede ser necesaria para el planificador.
o

2.4.3.

Estados del sistema y listas de procesos

Un estado de un proceso es s´lo un componente del estado global del sistema que
o
incluye a todos los procesos y recursos. Para controlar la evoluciń de todos los procesos,
o
el SO mantiene listas de BCPs clasificadas por el estado actual de los procesos aceptados.
En general, existir´ una lista con los BCPs de todos los procesos en situaciń de preparado
a
o
y una lista con todos los BCPs en situaciń de suspendido. Mediante estas listas el SO
o
forma colecciones de procesos en estados an´logos y serń examinadas por las rutinas de
a
a
asignaciń de recursos del SO.
o

30


ejemplo El planificador buscar´ el siguiente proceso a ejecutar en la lista de los BCPs
a
de procesos preparados.
El rendimiento del SO puede mejorar ordenando y actualizando estas listas de la manera
m´s conveniente para las rutinas del SO que operan con ellas. Las transiciones de estado
a
de un proceso quedarń reflejadas en el cambio de su BCP de una lista a otra.
a

2.4.4.

Conmutaciń de procesos
o

Una transiciń entre dos procesos residentes en memoria en un sistema multitarea se
o
denomina conmutaciń de procesos o conmutaciń de tareas. Las principales operaciones
o
o
implicadas en una conmutaciń de procesos estń resumidas en la figura 2.9.
o
a
Espacio de memoria de usuario

Espacio de memoria del SO

Px (Proceso)
Suceso
Cambio de modo
Conmutación
de procesos.
SO en
ejecución

Guardar el estado de Px en BCP(x)
Actualizar el estado de Px y los datos de planificación
Atención del suceso (Se consideran fuera del proceso de conmutación)
Planificación del siguiente proceso a ejecutar (Py)
Restaurar el estado HW de Py y sus atributos desde BCP(y)

Cambio de modo
Py(Proceso)

Figura 2.9: Esquema de conmutaciń de recursos
o

La figura se interpreta de la siguiente manera
Estamos en modo usuario con un proceso Px ejecutńdose. Ocurre un suceso.
a
Pasamos a modo supervisor (ejecutamos SO).
• Guarda el estado del proceso interrumpido en su BCP correspondiente
• Actualiza el estado de Px (en funciń del suceso que haya tenido lugar, el
o
estado ser´ uno u otro) y los datos de planificaciń (Algunos ssoo tienen
a
o
ciertas consideraciones para recalcular estos datos de planificaciń para un
o
proceso. Por ejemplo, restar prioridad a procesos largos.
• Atendemos al suceso dependiendo de cada caso (no incluimos esta operaciń
o
en lo que consideramos proceso de conmutaciń)
o


31

o
• Planificamos cu´l va a ser el siguiente proceso a ejecutar (que podr´ ser el
a
ıa
mismo de inicio).
• Una vez elegido el nuevo proceso a ejecutar, llam´mosle Py , hay que restaurar
e
su estado HW y recuperamos sus atributos gracias a su BCP.
Una vez elegido el nuevo proceso, realizamos un cambio de modo.
La conmutaciń de procesos es una operaciń considerablemente m´s compleja y costosa
o
o
a
que la conmutaciń del contexto de interrupciń y puede ser bastante complicada en ssoo
o
o
grandes que disponen de un mantenimiento preciso de recursos y de sofisticados esquemas
de planificaciń. Dada su complejidad y su relativamente alta frecuencia de ocurrencia,
o
la implementaciń de la conmutaciń de procesos puede afectar significativamente al
o
o
rendimiento de un SO de multiprogramaciń.
o
Es especialmente importante en sistemas donde el tiempo es un factor cr´
ıtico tales
comos los sistemas en tiempo real. La eficiencia de la conmutaciń de procesos puede ser
o
mejorada con ayuda del hardware y una estructura de software especial conocida como
hebra o hilo.
Un esquema hardware habitualmente empleado para la acelerar la conmutaciń de
o
procesos es disponer de m´ltiples conjuntos estructuralmente idńticos de registros del
u
e
procesador. Un conjunto para el SO y otro para los procesos de usuario. Un bit dedicado
en la unica copia de la palabra del estado del procesador indica el estado actual de
´
operaciń supervisor o usuario y el conjunto de registros activos. Este m´todo reduce el
o
e
gasto software por conmutaciń de modo y la mayor parte del proceso de almacenamiento
o
del estado hardware a la ejecuciń de unas pocas instrucciones de manipulaciń de bits.
o
o
Si se dispone de m´s de dos conjuntos de registros, se pueden aplicar ahorros similares a
a
los procesos de usuario hasta alcanzar el n´mero de conjuntos de registros disponibles.
u
Pregunta ¿Por qu´ la conmutaciń de procesos es m´s costosa que la conmutaciń del
e
o
a
o
contexto de interrupciń?
o

2.4.5.

Servicios del sistema operativo para la gestiń de procesos
o

Aunque los ssoo suelen diferir en su filosof´ y objetivos de diseõ sus capas del nćleo
ıa
n
u
m´s internas muestran una gran similitud en cuanto al tipo y rango de primitivas de
a
gestiń de procesos que ofrecen. Los detalles y par´metros var´ inevitablemente de un
o
a
ıan
sistema a otro, pero las funciones proporcionadas por la colecciń total de llamadas al
o
SO son muy parecidas. Esto es as´ porque el concepto de proceso es comń a todos los
ı
u
ssoo pero cada uno los gestiona de forma distinta.
El servicio de creaciń de procesos crear(Id_proceso, atributos): En respuesta a
o
esta llamada el SO crea un proceso con el identificador y los atributos especificados
o predeterminados por el sistema. El SO obtiene un nuevo BCP del conjunto de
memoria libre, rellena sus campos con los par´metros proporcionados y/o predea
terminados e inserta el BCP en la cola de procesos preparados 7 . De esta manera,
7

cuando un proceso tiene BCP ya puede ejecutarse por lo que ya estar´ en el nivel de Preparado.
a

32


el proceso especificado podr´ ser elegido por el SO para su ejecuciń. Algunos de
a
o
los par´metros o atributos que pueden definirse en el momento de creaciń de un
a
o
proceso son los siguientes:
1. Nivel de privilegios.
2. Nivel de prioridad.
3. Tamaõ y requisitos de memoria.
n
4. Informaciń sobre acceso a memoria y derechos de acceso a dispositivos de
o
E/S.
5. Tamaõ m´ximo del ´rea de datos y/o de la pila.
n
a
a
El servicio de terminaciń de procesos terminar(Id_proceso): La invocaciń de eso
o
ta llamada hace que el SO destruya el proceso designado y lo suprima del sistema.
El SO reacciona reclamando todos los recursos asignados al proceso especificado,
cerrando los archivos abiertos por o para el proceso y efectuando otras operaciones de que pueden considerarse necesarias y que dependerń de la naturaleza del
a
proceso. A continuaciń el BCP es eliminado de la lista en que resida y devuelto
o
al conjunto de posiciones libres. Un proceso puede eliminarse a s´ mismo pero no
ı
puede crearse a s´ mismo. Un proceso podr´ eliminar a otro siempre y cuando tenga
ı
a
privilegios para ello.
El servicio para abortar un proceso abortar(Id_proceso): Esta orden supone la
terminaciń forzosa de un proceso. El SO efectá generalmente muchas de las
o
u
acciones que conlleva la orden terminar. Habitualmente se proporciona un volcado
de registros y memoria junto con la informaciń relativa a la identidad del proceso
o
que se aborta y la razń de la acciń. El uso m´s frecuente de esta orden es para
o
o
a
terminaciones involuntarias.
ejemplo en MS Windows NT se produce una operaciń inv´lida y el SO lo aborta.
o
a
Aparece una ventana detalles en donde se ofrece un volcado del registro y
memoria.
El servicio dividir/unir fork()/join(): La operaciń dividir fork() se utiliza para
o
dividir una sencuencia de instrucciones en dos secuencias que se ejecutan concurrentemente. Se crea as´ un nuevo proceso (proceso hijo) que ejecuta una rama
ı
del c´digo dividido mientras el proceso padre continá ejecutando la otra. Esta
o
u
llamada proporciona al proceso padre el identificador del proceso hijo y lo utiliza
para asignarle una rama de c´digo. La operaciń unir join() se utiliza para reunir
o
o
las dos secuencias de c´digos divididos y puede ser empleada por un proceso padre
o
para sincronizarse con un proceso hijo.
ejemplo Esto se utiliz´ mucho en servidores de ficheros. Existe un proceso llamado
o
listener que se mantiene a la escucha. Cuando recibe la peticiń de un cliente
o
(identificado por una direcciń IP, etc). Listener realiza un fork() y al nuevo
o


33

o
proceso le proporciona la direcciń IP del cliente mientras el proceso Padre
o
sigue a la escucha.
El servicio para bloquear un proceso bloquear(Id_proceso): Como respuesta a esta
llamada, el proceso designado queda bloqueado idefinidamente y pasa a este estado.
Un proceso puede bloquearse a s´ mismo o puede bloquear a otro proceso cuando
ı
est´ autorizado para ello en virtud de su nivel de privilegio, prioridad o pertenencia
a
a una familia.
Servicio para reanudar un proceso reanudar(Id_proceso): Esta llamada al sistema
saca un proceso del estado de bloqueo impuesto por la llamada anterior, el BCP
del proceso pasa a la lista de preparados. Un proceso no puede reanudarse a s´
ı
mismo si est´ en estado de bloqueo indefinido, por lo que si se encuentra en
a
esta situaciń no podr´ continuar hasta que sea reanudado.
o
a
Servicio para retardar un proceso retardar(Id_proceso, tiempo): Esta orden es
conocida en bastantes ssoo como sleep y bloquea a un proceso durante un tiempo
igual al especificado.
Servicio para leer los atributos de un proceso leer_Atributos(Id_proceso,atributos):
Esta llamada vuelca en la estructura suministrada el conjunto de atributos del proceso.
Servicio para modificar la prioridad de un proceso modificar_Prioridad(Id_proceso,
nuevo_valor_prioridad): Esta llamada al sistema establece como nueva prioridad
del proceso la especificada por par´metros.
a

34


3 Planificaciń de procesos
o
3.1.

Concepto y criterios de planificaciń
o

La planificaciń hace referencia a un conjunto de pol´
o
ıticas y mecanismos incorporados
al SO que gobiernan el orden en que se ejecutan los trabajos que deben ser completados
por el sistema inform´tico. Un planificador es un m´dulo del SO que selecciona el sia
o
guiente trabajo a admitir en el sistema y el siguiente proceso que tomar´ el control sobre
a
el procesador. El objetivo primario de la planificaciń es optimizar el rendimiento del
o
sistema de acuerdo con los criterios considerados m´s importantes por los diseãdores
a
n
del mismo.
Entre las medidas de rendimiento y los criterios de optimizaciń m´s habituales que
o
a
los planificadores utilizan para llevar a cabo su labor se encuentran los siguientes:

3.1.1.

Utilizaciń del procesador:
o

La utilizaciń del procesador es la fracciń de tiempo promedio durante la cual el
o
o
procesador est´ ocupado, es decir, la fracciń de tiempo durante la cual el procesador se
a
o
encuentra activo ejecutando algń proceso, bien de usuario, bien del propio SO. Con esta
u
interpretaciń, la utilizaciń del procesador puede ser medida con relativa facilidad, por
o
o
ejemplo mediante un proceso nulo especial1 que se ejecute cuando ningń otro proceso
u
pueda hacerlo. Una alternativa es considerar unicamente la operaciń en modo usuario
´
o
y, por tanto, excluir el tiempo empleado para el SO2 .
En cualquier caso, el objetivo es mantener al procesador ocupado tanto tiempo como
sea posible. De esta forma, se conseguir´ que los factores de utilizaciń de los restantes
a
o
componentes tambiń sean elevados obtenińdose con ello buenas medidas de rendimiene
e
to.

3.1.2.

Productividad

La produtividad se refiere a la cantidad de trabajo completada por unidad de tiempo.
Un modo de expresarla es definińdola como el n´mero de trabajos de usuario ejecutados
e
u
por una unidad de tiempo. Cuanto mayor sea este n´mero, m´s trabajo aparentemente
u
a
est´ siendo ejecutado por el sistema.
a
1

en MINIX existe un proceso llamado idle:

idle(){
for(;;);
}
2

Podr´
ıamos decir que el tiempo de uso real del procesador es el tiempo total de uso menos el tiempo que
se estuvo ejecutando la instrucciń idle().
o

35

Sistema operativo

Recomendados

Recomendados

Mais conteúdo relacionado

Mais procurados

Mais procurados (16)

Destaque

Destaque (8)

Semelhante a Sistema operativo

Semelhante a Sistema operativo (20)

Sistema operativo