TORRES, Jose - Conceptos de Sistemas Operativos

CONCEPTOS DE
SISTEMAS
OPERATIVOS José Torres Jiménez
trillas
Digitalización con propósito academico. Sistemas operativos
CONCEPTOS DE
SISTEMAS
OPERATIVOS José Torres Jiménez
Preedición
EDITORIAL
TRILLAS
México, Argentina, España
Colombia, Puerto Rico, Venezuela

Presentación
El presente libro tiene como objetivo primordial, el servir como material de apoyo
para el curso de Sistemas Operativos que se imparte en el ITESM (Instituto
Tecnológico y de Estudios Superiores de Monterrey). El curso de sistemas operativos
es llevado por los alumnos de las carreras ISE (Ingenieros en Sistemas Electrónicos),
ISI (Ingenieros en Sistemas de Información), isc (Ingenieros en Sistemas
Computacionales) y LSCA (Licenciados en Sistemas Computacionales
Administrativos). Adicionalmente este libro podrá ser utilizado por interesados en
aprender los fundamentos de los sistemas operativos.
Es recomendable, para un mejor entendimiento del material de este libro, el tener
conocimientos de algún lenguaje de programación (en particular es muy útil el conocer
previamente el lenguaje C o el lenguaje Java), tener conocimientos sobre arquitecturas
computacionales y sobre estructuras de datos.
El libro persigue el presentar la manera en que los recursos de un sistema
computacional son controlados por un sistema operativo. El libro está organizado en 9
capítulos:
1. Conceptos Básicos. En este capítulo se presenta la evolución histórica de los

sistemas operativos y de manera breve conceptos de Hardware, Firmware y
Software que son útiles para el entendimiento de los diferentes algoritmos que serán
presentados a lo largo de todo el libro.
2. Manejo de Procesos. Este capítulo presenta los conceptos de Rutina, Co-rutina,
Procesos e Hilos, los cuales son necesarios para comprender la manera en la cual un
sistema operativo controla la realización de todo el trabajo en un sistema
computacional.
3. Manejo de Procesadores. Aquí se presentan los diferentes algoritmos que existen
para controlar la asignación de unidades de trabajo a un procesador o a varios
procesadores.
4. Manejo de Concurrencia y Sincronización. La manera en la cual es posible que
dentro de un sistema computacional ocurran de manera coordinada actividades
concurrentes es gracias a los diferentes algoritmos de manejo de concurrencia y
sincronización que son presentados en este capítulo.
5. Manejo de Memoria Real. En este capítulo se presenta la evolución histórica de
los diferentes esquemas de manejo de memoria real.
6. Manejo de Memoria Virtual. Aquí se presentan los diferentes esquemas para el
manejo de memoria virtual (la capacidad de accesar un espacio de direcciones
mayor que el de la memoria principal de la computadora).

6 PRESENTACIÓN
7. Manejo de Interbloqueo. Se presentan diferentes algoritmos de manejo de

Interbloqueo, se destaca la presentación de algoritmos secuenciales y concurrentes.
8. Manejo de Archivos y Discos. La organización del sistema de archivos es
presentada de la misma manera que las estrategias para la optimización del manejo de
disco.
9. Sistemas Operativos Distribuidos. Se dan los conceptos básicos de los sistemas
operativos distribuidos.
Con base en estos conocimientos el alumno podrá entender y evaluar el desempeño de

sistemas operativos de actualidad.

Índice de contenido
Presentación 5
1 Introducción a los sistemas operativos 15

1.1 Conceptos de sistemas operativos 15
1.1.1 Generaciones de sistemas operativos 16
1.2 Hardware, Firmware y Software 16
1.2.1 Hardware 16
1.2.2 Software 17
1.2.3 Firmware 18
1.3 Evolución de la programación concurrente 18
1.3.1 (1955—1960) El reto del hardware 18
1.3.2 (1960—1965) La crisis del software 18
1.3.3(1965—1970) Inovación conceptual 19
1.3.4(1970-1975) Desarrollo de lenguajes 19
1.3.5(1975—) Entendimiento formal 20
1.3.6(1980-) Refinamiento del hardware 20
1.3.7 (1980-) Redes de computadoras 20
1.4 Referencias 21
2 Manejo de procesos 23
2.1 Introducción 23
2.2 Definición de proceso 23
2.3 Estados de un proceso 23
2.4 Bloque de control de un proceso (PCB) 24
2.5 Operaciones sobre procesos 24
2.6 Creación jerárquica vs creación no jerárquica 25
2.7 Procesamiento de interrupciones 25
2.8 Tipos de interrupciones 25
2.9 Funciones del núcleo (kernel) 25
2.10 Deshabilitación/habilitación de interrupciones 26
2.11 Estructura jerárquica de un sistema operativo 26
2.12 Migración del núcleo a microcódigo 26
7
8 ÍNDICE DE CONTENIDO
2.13 Rutinas, corrutinas, procesos e hilos 26

2.13.1 Rutina 26
2.13.2 Corrutina 26
2.13.3 Proceso 27
2.13.4 Hilos 27
2.14 Referencias 28
3 Algoritmos de administración de procesadores 29
3.1 Objetivos de la asignación de procesadores 29
3.2 Criterios de la asignación de CPU 29
3.3 Asignación preemptive vs no-preemptive 30
3.4 Manejo de quantum 30
3.5 Prioridad 30
3.6 Asignación de CPU FIFO 31
3.7 Asignación de CPU Round Robin 31
3.8 Asignación de CPU Shortest Job First (SJF) 31
3.9 Asignación de CPU Shortest Remaining Time First 32
3.10 Asignación de CPU de colas con retroalimentación multiniveles 32
3.11 Asignación de CPU selfish round robin (SRR) 32
3.12 Asignación de CPU con algoritmos híbridos 33
3.13 Asignación de CPU dependientes del estado 33
3.14 Asignación de CPU basados en prioridades externas 33
3.15 Referencias 34
4 Administración de memoria real 35
4.2 Organización 35
4.3 Administración del almacenamiento 36
4.4 Jerarquía de almacenamiento 36
4.5 Estrategias de administración de almacenamiento 37
4.5.1 Estrategias de Fetch 37
4.5.2 Estrategias de localización 37
4.5.3 Estrategias de reemplazo 37
4.6 Asignación de almacenamiento contiguo vs. No-contiguo 37
4.6.1 Asignación de almacenamiento contiguo a un sólo usuario 38
4.6.2 Protección en sistemas de un sólo usuario 38
4.7 Sistemas Tipo Batch 39
4.8 Multiprogramación de partición fija 40
4.9 Multiprogramación de partición fija, traducción y cargado absoluto 40
4.10 Multiprogramación de partición fija con cargado y traducción relocalizable42
4.11 Protección en sistemas de multiprogramación 42
4.12 Fragmentación en sistemas de multiprogramación de partición fija 42
4.13 Multiprogramación de partición variable 43
4.14 Compactación de almacenamiento 43
4.15 Estrategias de localización de almacenamiento 45

ÍNDICE DE CONTENIDO 9
4.15.1 Estrategia Best Fit 45

4.15.2 Estrategia First Fit 46
4.15.3 Worst Fit 46
4.15.4 Estrategia Buddy Fit 46
4.15.5 Estrategia Fibonacci Fit 47
4.16 Fragmentación interna 47
4.17 Fragmentación externa 47
4.18 Comparación de estrategias de localización 47
4.19 Multiprogramación con intercambio de procesos en almacenamiento 47
4.20 Referencias 48
5 Memoria virtual 49
5.1 Conceptos básicos de almacenamiento virtual 49
5.2 Organización de almacenamiento multiniveles 51
5.3 Mapeo de bloques 51
5.4 Dirección de mapeo de bloques 51
5.5 Conceptos básicos de paginación 51
5.6 Traducción de direcciones de paginación por mapeo directo 53
5.7 Traducción de direcciones de paginación por mapeo asociativo 54
5.8 Traducción de direcciones de paginación combinando mapeo
asociativo y directo 54
5.9 Compartición en un sistema de paginación 54
5.10 Segmentación 54
5.11 Sistemas de paginación con segmentación 56
5.12 Administración del almacenamiento virtual 56
5.12.1 Estrategias de administración de almacenamiento virtual 56
5.12.2 El principio de optimalidad 57
5.12.3 Reemplazo de página aleatorio 57
5.12.4 Reemplazo de página FIFO 57
5.12.5 Reemplazo de página menos recientemente usada (LRU) 58
5.12.6 Reemplazo de página menos frecuentemente usada (LFU) 59
5.12.7 Reemplazo de página no usada recientemente (NUR) 59
5.12.8 Localidad 60
5.12.9 Conjuntos de trabajo (Working Sets) 60
5.12.10 Paginación por demanda 61
5.12.11 Paginación anticipatoria 61
5.12.12 Liberación de páginas 61
5.12.13 Tamaño de página 61
5.12.14 Comportamiento de un programa bajo paginación 62
5.13 Referencias 62
6 Sincronización y comunicación de procesos 63
6.1 Concurrencia de procesos 63
6.2 Suma de dos matrices 63
6.3 Ecuación cuadrática 64

6.4 Problema de la actualización perdida 64

6.5 Exclusión mutua 65
6.6 Algoritmo de Dekker (Memory Interlock) 65
6.6.1 Algoritmo para construir un diagrama de estados de la ejecución
concurrente de procesos 65
6.6.2 Versión 1 de Memory Interlock 66
6.6.3 Versión 2 dc Memory Interlock 67
6.6.6 Solución final de Memory Interlock (Algoritmo de Dekker) 71
6.7 Problema de exclusión mutua usando intercambios (Test and Set) 72
6.8 Algoritmo de Peterson para Exclusión mutua 73
6.9 Semáforos 74
6.9.1 Exclusión mutua con semáforos 75
6.9.2 Problema del productor/consumidor 76
6.9.3 Problema de lectores y escritores 82
6.9.4 Problema de los filósofos 88
6.9.5 Problema de K-Procesos en la sección crítica 90
6.9.6 Problema de los fumadores de cigarros 93
6.10 Pipes 97
6.11 Paso de mensajes (Mailboxes, puertos) 98
6.12 Regiones críticas 98
6.13 Regiones críticas condicionales 98
6.14 Interrupciones virtuales 99
6.15 Expresiones de trayectoria 99
6.16 Expresiones invariantes 100
6.16.1 Ejemplo de productores consumidores 101
6.16.2 Ejemplo de lectores y escritores 101
6.17 Contadores de eventos 102
6.17.1 Secuenciadores 103
6.18 Monitores 104
6.18.1 Monitor tipo monitor 106
6.18.2 Monitor tipo manager 106
6.18.3 Monitor tipo mediador 107
6.18.4 Monitor tipo gladiador 107
6.19 Referencias 108
7 Manejo de interbloqueo (Deadlock) 109
7.2 Algoritmos de prevención de deadlock 110
7.2.1 Definición de un sistema de asignación de recursos 110
7.2.2 Representación del estado del sistema 110
7.2.3 Consideraciones básicas 110
7.2.4 Definición de estado seguro 111
7.2.5 Algoritmo de Habermann 111

7.2.6 Algoritmo de Fontao 111
7.3 Algoritmos dc detecciónlcorrcción de deadlock 116
7.3.1 ¿Cuánto correr? 116
7.3.2 ¿Cómo detectar cl deadlock? 117
7.3.3 ¿Cómo corregir el deadlock? 118
7.4 Referencias 118
8 Manejo de archivos y discos 119
8.2 Sistema de archivos 119
8.3 Organización de archivos 119
8.3.1 Archivo secuencial 120
8.3.2 Archivo ordenado usando búsqueda binaria 120
8.3.3 Archivo secuencial indizado 121
8.4 Estructura de un disco duro 121
8.4.1 Tiempo de acceso a los datos 122
8.5 Tiempo de búsqueda, tiempo de latencia y tiempo de transmisión 123
8.6 Algoritmos de planificación de tiempos de búsqueda 124
8.6.1 Algoritmo SSTF (Shortes Seek Time First) 124
8.6.2 Algoritmo SCAN 124
8.6.3 Algoritmo N-Step Scan 124
8.6.4 Algoritmo C-Scan (Circular Scan) 124
8.7 Optimización rotacional 125
8.8 Referencias 125
9 Sistemas operativos distribuidos 127
9.2 El protocolo TCP/IP 127
9.3 Computación cliente/servidor 128
9.4 Migración de procesos 129
9.5 Referencias 129
A Unix 131
A. 1 Introducción a Unix 131
A.1.1 Historia de Unix 131
A.1.2 Características de diseño de Unix 132
A.1.3 Estructura de Unix 132
A.1.4 Kernel de Unix 132
A. 1.5 El sistema de archivos 132
A.1.6 El Shell 134
A.1.7 Aplicaciones/lenguajes de Unix 134
A.1.8 Comunicaciones y manejo de redes 134
A. 1.9 Editorcs/formateadores de texto 135
A.l.lO Comandos básicos de Unix 135
A.2 Manejo de archivos 138

A.2. 1 Definición de archivo 138
A.2.2 Tipos de archivos 138
A.2.3 Estructura del sistema de archivos y trayectorias 138
A.2.4 Nombres de archivos 140
A.2.5 Comandos para manejos de archivQs 140
A.2.6 Comandos para manejo de grupos y propietarios 140
A.3 Procesos 141
A.3.1 Características de un proceso en Unix 141
A.3.2 Creación de un proceso 141
A.3.3 Procesos de frente y fondo 143
A.3.4 Corres procesos después de salir 143
A.3.5 Controlando la prioridad de los procesos 143
A.3.6 Terminando procesos 144
A.4 El Shell 144
A.4.1 Descripción del Shell 144
A.4.2 Archivos estándar 144
A.4.3 Redirección 145
A.4.4 Continuación y agrupación de comandos 145
A.4.5 Pipes y filtros 145
A.4.6 Metacaractcres 146
A.4.7 Variables de Shell 146
A.4.8 Exportando variables 147
A.4.9 Variables como comandos 147
A.4.10 Caracteres de escape dc Shell 148
A.4.11 Tipos de Shell 148
A.4.12 Terminales virtuales 150
A.4.13 Comandos de selección 150
A.5 Editores 151
A.5.1 Editores de Unix 151
A.5.2 El editor vi 152
A.6 Herramientas de manejo de datos 154
A.6.1 El comando find 154
A.6.2 El comando grep a detalle 154
A.6.3 El comando cut 154
A.6.4 El comando diff 155
A.7 AIX Windows 155
A.7.l Terminales virtuales 155
A.7.2 Historia de XWindows 156
A.7.3 Modelo cliente-servidor 156
A.7.4 Salida de AlXWindows 156
A.7.5 Ventana raíz 157
A.7.6 Distribución de una ventana 157

A.7.7 Manejo de teclado 157

A.7.8 Manejo de AlXWindows en red 157
A.7 .9 Personalización de clientes 158
A.8 Sincronización/comunicación de procesos 158
A.8.1 Procesos en Unix 158
A.8.2 Creación de un proceso 160
A.9 Comunicación interprocesos 162
A.9.1 Pipes 163
B Java 177
B. 1 Introducción 177
B.2 Historia 178
A.3 Diferencias entre Java y C 179
B.3.1 Estructura del programa 179
B.3.2 Argumentos 179
B.3.3 Valor de salida en un programa 179
B.3.4 Estatuto import 179
B.3.5 Caracteres para comentarios 180
B.3.6 Constantes 180
B.3.7 Tipos de datos 180
B.3.8 Colección de basura 180
B.3.9 Apuntadores 181
B.3.10 Strings 181
B.3.l1 Arreglos 181
B.4 Programación en Java 181
B.4.l Objeto 181
B.4.2 Clase 182
B.4.3 Método 182
B.4.4 Instancia 182
B.4.5 Herencia 183
B.5 Aplicaciones y Applets 183
B.5. 1 Cómo crear o editar un programa 184
B.5.2 Cómo compilar un programa 184
B.5.3 Cómo ejecutar una aplicación 184
B.5.4 Cómo ejecutar un Applet 185
B.5.5 Métodos básicos de un Applet 185
B.5.6 Ejemplo de una aplicación 185
B.5.7 Ejemplo de un Applet 188
B.6 Hilos 190
B.6. 1 Constructores 191
B.6.2 Métodos 191
B.6.3 Ejemplo de Threads 192
C Baci 195
C. 1 Introducción 195

C.2 El lenguaje C— 195

C.3 Creación de procesos 196
C.4 Manejo de semáforo 196
C.5 Manejo de monitores 197
C.6 Otras instrucciones 197
C.7 Usando Baci 198
C.8 Ejemplo 198
C.9 ¿Dónde está siendo utilizado Baci? 199
C.10¿Dónde conseguirBaci? 199
D JPNS 201
D. 1 Introducción 201
D.2 Instalando jPNS 201
D.2.1 Como Applet 201
D.2.2 Como aplicación 201
D.3 Los comandos de jPNS 202
D.3.1 Menú File 202
D.3.2 Menú Settings 202
D.4 Los iconos gráficos 202
D.5 Ejemplo de red de petri en Jpns 205
Bibliografía 207

Capítulo 1
Introducción a los
sistemas operativos
En este capítulo describiremos conceptos básicos de sistemas operativos,
hardware, firmware y software. Adicionalmente daremos una breve panorámica de la
evolución histórica de los sistemas operativos.
1.1. Conceptos de Sistemas Operativos
Se puede decir que un sistema operativo (SO) es el conjunto de programas que

permiten que sea usable una computadora, aunque de una manera más precisa, un
sistema operativo es el conjunto de programas implementados en Software o Firmware
que hacen posible que se use el Hardware.
Algunas de las funciones y facilidades que debe proporcionar un SO son:
• Manejo de recursos.
• Definición de interfaz usuario.
• Compartición de hardware
• Compartición de datos.
• Asignación de recursos.
• Recuperación de errores.
Los recursos que maneja un SO son:
• Procesadores.
• Almacenamiento.
• Dispositivos de E / S.
• Datos.
15

16 CAP 1. INTRODUCCIÓN A LOS SISTEMAS OPERATIVOS
1.1.1.Generaciones de Sistemas Operativos
40’s Generación 0. No existía un SO en las primeras computadoras. Los programas se

introducían manual y mecánicamente.
50’s Generación 1. En esta generación se usaron los SO BATCH.
Inicio 6O’s Generación 2. Los SO de esta generación se caracterizan por manejar:
Multiprogramación Multiprocesamiento Independencia de dispositivos, Tiempo
compartí. doy Tiempo real.
Med 6O’s-med 70’s Generación 3. En esta generación surgen los SO de propósito
general y que son capaces de manejar diversos tipos de aplicaciones en el mismo SO
(Batch, Multiprocesamiento, Tiempo real). Surge el SO de IBM 05360 y el SO UNIX.
Fines 70’s-SO’s. Generación 4. Surgen las Redes de computadoras y el énfasis es en
SO amigables. SO representativos de esta generación son: UNIX, VAX / VMS, CP-M,
MVS, VM, MS-DOS, MacIntosh.
90’s Generación 5. Surgen las redes de amplía cobertura (Internet), se habla de
migración de procesos para uso eficiente de la computación distribuida, surgen las
arquitecturas cliente/servidor y aplicaciones totalmente abiertas capaces de correr en
diversas plataformas de hardware y diversos SO.
1.2.Hardware, Firmware y Software
1.2.1. Hardware
El HW de un sistema computacional está compuesto principalmente de:

Elementos de Procesamiento, Dispositivos de Almacenamiento y Dispositivos de
Entrada / salida. Dado que para entender algunas funciones de un SO es necesario
conocer conceptos relacionados con la operación del ¡1W, comentaremos brevemente
algunos de estos conceptos:
1. Registros de relocalización. Estos registros permiten que tanto los datos, el código
y el stack puedan ser relocalizados sin necesidad de modificar el código original de
un programa. Esto es realizado usando dos tipos de registros: a) Un registro de
segmento que define la dirección base a partir de donde se encuentran el código, los
datos o el espacio de stack; y b) Un registro de desplazamiento que toma como
referencia al registro de segmento. De esta manera al modificar el valor del registro
de segmento, se está cambiando la dirección que se puede accesar.
2. Interrupciones y Polling. Cuando una aplicación se queda verificando
continuamente la ocurrencia de un evento, se dice que está diseñada para usar
POLLING. Cuando la aplicación continúa realizando otras actividades y cuando se
ocurra el evento se indica con una señal (interrupción) que ya ocurrió el evento, se
dice que está diseñada para usar INTERRUPCIONES. En general es preferible no
usar POLLING dado que es muy ineficiente el estar verificando continuamente la
ocurrencia de eventos.
3. Búferes. Cuando dos elementos se comunican y existe diferencia en la velocidad de
procesamiento de ellos, la velocidad de operación total será equivalente a la
velocidad

1.2. HARDWARE, FIRMWARE Y SOFTWARE 17
del elemento más lento. Para compensar las diferencias de velocidad entre
elementos que se comunican, se puede agregar memoria entre ellos (esto es un
buffer) lo cual ayuda a suavizar las diferencias de velocidad entre ellos (por
ejemplo la conexión entre una computadora y una impresora puede funcionar mejor
usando un buffer, que está localizado internamente en la impresora).
4. Temporizador de Quantum. Para poder soportar que un solo procesador sea
compartido entre varias aplicaciones se hace uso de un temporizador de quantum
(similar a un reloj despenador) el cuál permite asignar “rebanaditas” de tiempo
entre los diversos procesos.
5. Estado Problema / Estado Supervisor. Cuando el procesador de un sistema
computacional está asignado a una aplicación del usuario se dice que el sistema está
en Estado Problema, cuando el procesador está asignado al sistema operativo se
dice que el sistema está en el Estado Supervisor.
6. Manejo de Memoria Virtual. A la capacidad de accesar más memoria que la
disponible físicamente se le denomina Manejo de Memoria Virtual. En este manejo
las instrucciones de un programa accesan direcciones mas allá del espacio real de
memoria.
7. Multiprogramación (Multitarea o Multitasking). La multiprogramación permite

tener la “impresión” de que existe simultaneidad en la ejecución de los procesos a
pesar de solo tener un elemento de procesamiento.
8. Multiprocesamiento. Cuando un sistema tiene más de un elemento de
procesamiento es posible que se corran simultáneamente más de un proceso
1.2.2. Software
Para entender la operación de diversos algoritmos usados en los sistemas operativos
es necesario conocer algunos conceptos importantes de software son relacionados en
seguida:
1. Programación en Lenguajes de Máquina. Se refiere a los programas hechos en
lenguaje binario, los cuales pueden ser ejecutados directamente en el HW del
sistema computacional.
2. Ensambladores y Macroprocesadores. Usando un ensamblador y
macroprocesador es posible facilitar la generación de aplicaciones, dado que se
usan instrucciones cortas que relacionan directamente la operación de un
procesador en particular. El ensamblador genera a partir de las instrucciones codas
un programa en lenguaje maquinal.
3. Compilador. Es un programa que recibe como entrada un programa en lenguaje de
alto nivel (similar en cierto sentido a un lenguaje natural) y produce como salida un
programa en lenguaje ensamblador y/o lenguaje maquinal.
4. Intérprete. En lugar de realizar el proceso total de conversión de un programa en
lenguaje de alto nivel a lenguaje de bajo nivel, un intérprete va tomando instrucción
por instrucción del lenguaje de alto nivel y las ejecuta directamente.
18 CAP I. INTRODUCCIÓN A LOS SISTEMAS OPERATIVOS
1.2.3. Firmware
El firmware se puede decir que es SW implementado en HW, surgió en 1951 con la

microprogramación planteada por primera vez por Maurice Wilkes. Una de las
tendencias fuertes en los SO es el desplazar cada vez mas las funciones del SW al HW.
1.3.Evolución de la Programación Concurrente
Un programa concurrente es aquél que permite a una computadora hacer varias

cosas en forma simultánea.
El desarrollo abarca las siguientes etapas: Reto de hardware (1955-1960), Crisis de
software (1960-1965), Innovación conceptual (1965-1970), Desarrollo de lenguajes
(1970-1975), Entendimiento formal (1975 - ), Refinamiento de hardware (1980 - ) y
Redes de computadoras (1980-).
1.3.1. (1955-1960) El reto de Hardware

• Surgen interrupciones para compartir eficientemente un procesador con los
periféricos lentos.
• Los programas se hicieron tan complejos que fue imposible que un solo
programador los entendiera.
• Surgen los primeros lenguajes de alto nivel: FORTRAN y ALGOL 60.
• La ejecución concurrente de programas trajo un gran problema: la depuración de
programas concurrentes, debido a que un error se presentaba en forma errática
dependiendo del tiempo.
• No era posible reproducir una ejecución de un programa concurrente, a diferencia
de un programa secuencial en el que bajo la misma entrada se obtiene la misma
salida.
1.3.2. (1960-1965) La crisis de Software

• Debido a los problemas resultantes en la anterior etapa surgió la necesidad de
presentar al usuario una interface secuencial.
• El sistema de programación resultante debería de hacer de un sistema de cómputo
algo:
- Simple.
- Confiable
- Eficiente.
A éste sistema de programación se le llamó “sistema operativo”.
• Los primeros sistemas operativos tipo batch (atlas y exec II) eran eficientes y
simples pero no confiables totalmente.
• El problema de deadlock no era entendido muy bien.
• Los siguientes sistemas operativos fueron muy complejos:
MULTICS (1965)—200 hombres-año.

1.3.EVOLUCIÓN DE LA PROGRAMACIÓN CONCURRENTE 19
OS360 (1966)—5000 hombres-año.

La cantidad de errores en éstos sistemas era alarmante: en cada liberación del
05360 se tenían aproximadamente 1000 errores.
• Es entonces cuando surge el sentimiento de que no era posible diseñar programas
concurrentes grandes sin contar con una fuerte base conceptual.
1.3.3. (1965-1970) Innovación Conceptual
• Surge la necesidad de dividir un programa concurrente en pequeños módulos

asíncronos con comportamiento independiente del tiempo.
• Surge el concepto de proceso como: “ un módulo de programa que consiste de una
estructura de datos y una secuencia de enunciados que operan sobre ella”.
• Como los procesos comparten recursos y/o cooperan en tareas comunes deben
compartir datos de una manera controlada surgiendo la necesidad de
sincronización.
• Dijkstra comentó:”Si procesos operan simultáneamente sobre las mismas variables
a velocidades impredecibles el resultado también será impredecible “, por lo cual
estableció que las operaciones sobre las variables comunes deben hacerse una a la
vez, surgiendo el concepto de “región crítica
• Dijkstra estableció el caso más simple de intercambio de señales de tiempo
inventando una estructura de datos llamada “semáforo” con dos funciones de
acceso P y V con propiedad conmutativa.
• Dijkstra demostró la implementación de regiones críticas y comunicación entre
procesos usando semáforos.
• Dijkstra con su sistema “THE” demostró que a través del ordenamiento jerárquico
en capas se le puede dar una imagen más placentera al usuario.
• Habermann mostró que a través de un ordenamiento jerárquico de los
requerimientos de los recursos se pueden prevenir deadlocks.
1.3.4. (1970-1975) Desarrollo de Lenguajes
• Se caracteriza por el desarrollo de una tecnología y notación precisa de los

conceptos concurrentes.
• Dijkstra en su sistema “THE” manejé el concepto de concurrencia a través del
enunciado: COBEGIN S1;S2;S3; COEND.
• Hoare introdujo el concepto de región crítica condicional, esto es que la entrada a
una región crítica era condicionada a una variable booleana.
• Dijkstra sugirió que las interacciones de los procesos se podían concentrar en
ciertos módulos de los programas.
• Siguiendo la idea anterior Hoare propone en 1973 la notación para el concepto
denominado “monitor”.
• El monitor consta de estructuras de datos propias accesibles sólo a través de
procedimientos propios y una parte de inicialización.
• Surge la idea de que un compilador auxilie en la creación de programas
concurrentes.

20 CAP I. INTRODUCCIÓN A LOS SISTEMAS OPERATIVOS
• El primer lenguaje es: “pascal concurrente” (1974) que soporta el concepto de

proceso y monitor.
• Después surge MODULA (1977) soportando el concepto de proceso y monitor
• De ésta forma un programa concurrente podría ser hecho de pequeños módulos que
en cierta forma semejaban un programa secuencial.
1.3.5. (1975- ) Entendimiento Formal
• Surge la idea de verificación de programas.

• Hoare introduce definiciones “axiomáticas” del significado de enunciados
concurrentes, regiones críticas y monitores.
• Dijkstra introdujo una notación de comandos “guardados” y en base a ella hacer la
“derivación formal” de programas.
• Esta etapa está en su infancia.
1.3.6. (1980- ) Refinamiento de Hardware
• Debido a que los costos del hardware disminuyen y los de software aumentan surge
la idea de soportar directamente los conceptos de proceso y monitor en hardware
(microprocesador).
• Surge la idea de escribir un programa concurrente independientemente del HW en
donde correrá, probarlo y después diseñar la arquitectura más adecuada al software.
• Cada vez se tendrá HW más especializado de acuerdo a la aplicación.
• Esta etapa continúa.
1.3.7. (1980-) Redes de Computadoras
• Ha tomado aproximadamente 20 años diseñar sistemas de cómputo confiables en

los cuales procesos concurrentes comparten almacenamiento.
• Surge la idea de redes de computadoras en las que la comunicación no sea por
memoria compartida sino por F/S.
• Este enfoque es más natural para aplicaciones de tiempo real.
• Parece que éste enfoque es la solución para comunicación por mensajes en sistemas
distribuidos.
• Surgen conceptos de paso de mensajes “No determinístico” y “Procesos
distribuidos” que no están entendidos del todo, indicando la necesidad de nuevos
conceptos para la computación distribuida.
• Se espera que esté bien entendida la computación distribuida por el año 2000.
• Si la evolución de la programación es cíclica se espera:
- Nuevo reto de HW.

- Surgiendo una crisis de SW.
- La búsqueda de nuevos conceptos.
- Nuevos lenguajes de programación.

1.4. REFERENCIAS 21
- Nuevas teorías.
- Etcétera.
1.4. Referencias
Para tener un mayor entendimiento de los temas vistos en este capítulo se

recomiendan las siguientes lecturas adicionales (ver referencias al final del libro):
[1], [2], [3], [4], [5], [6], [7], [8], [9], [10], [11], [12], [13].

Capítulo 2
Manejo de procesos
En este capítulo presentaremos los detalles relativos a la manipulación de procesos
por parte del Sistema Operativo. Usando un diagrama de estados y transiciones de los
procesos se explican todas las posibles operaciones relacionadas con procesos.
2.1.Introducción
A través de los procesos es como es posible realizar un trabajo utilizando un
sistema operativo. Los estados y transiciones de un proceso son ilustrados en la figura
2.1
2.2.Definiciones de proceso
• Un programa en ejecución.
• Una actividad asíncrona.
• El espíritu animado de un procedimiento.
• El lugar de control de un procedimiento en ejecución.
• Lo que se manifiesta por el PCB dentro de un SO.
• La entidad a la que se le asignan procesadores.
• La unidad despachable.
2.3.Estados de un proceso
• Corriendo.
• Listo.
• Bloqueado.
• Eliminado.
• Suspendido Listo.
• Suspendido Bloqueado.
23
24 CAP 2. MANEJO DE PROCESOS
Figura 2.1. Diagrama de los estados de un proceso.
2.4. Bloque de control de un proceso (PCB)
• Estado actual de un proceso.

• Identificación única del proceso.
• Prioridad del proceso.
• Dirección de memoria.
• Recursos asignados.
• Área de registros de CPU.
2.5.Operaciones sobre procesos
• CREAR. Nombrar al proceso, insertarlo en la lista de procesos, determinar su

prioridad inicial, crear su PCE, asignar los recursos iniciales.
• DESTRUIR. Quitar recursos al proceso, eliminarlo de la lista de procesos, borrar su
PCB.
• SUSPENDER. Quitarle los recursos temporalmente.
• REINICIAR. Reasignarle los recursos.
• CAMBIO DE PRIORIDAD. Modificar el atributo correspondiente en el PCB.

2.10. DESHABILITACIÓN / HABILITACIÓN DE INTERRUPCIONES 25
• BLOQUEO. Quitarle el procesador esperando por la ocurrencia de un evento. Se

inserta el proceso en la cola de bloqueados.
• DESBLOQUEO. Al ocurrir el evento esperado se inserta el proceso en la cola de
listos.
• DESPACHO. Asignación del procesador a un proceso.
2.6. Creación jerárquica vs. creación no jerárquica

En la creación jerárquica un proceso creado depende del proceso que lo creo, de
manera que al terminar el proceso creador termina necesariamente el proceso creado.
En la creación no jerárquica el proceso creado puede continuar ejecutándose a pesar de
que el proceso creador ya termino.
2.7. Procesamiento de interrupciones

• SO. Gana el control.
• SO. Guarda status de proceso interrumpido.
• SO. Transfiere el control a ISR.(Rutina de Servicio de Interrupción).
2.8. Tipos de interrupciones

• Supervisor CalIs (SVC) (pedir más memoria).
• FIS.
• Externas(quantum).
• Reinicio del Sistema.
• Chequeos de programa (división por cero).
• Chequeos de máquina.
• Interrupciones NMI y MI.
2.9. Funciones del núcleo (Kernel)
• Manejo de interrupciones.
• Creación / destrucción de procesos.
• Cambios de estado de un proceso.
• Despacho de procesos.
• Suspensión y reinicio de procesos.
• Sincronización de procesos.
• Comunicación interprocesos.
• Manejo de PCB’s.
• Soporte de actividades de 110.
• Soporte de asignación / desasignación de recursos.
• Soporte del sistema de archivos.
• Soporte del mecanismo de llamadas y regresos de procedimientos.
• Soporte de funciones de contabilidad del sistema.

2.10. Deshabilitación/habilitación de interrupciones
• SO con interrupciones deshabilitadas.

• Usuario con interrupciones habilitadas.
2.11. Estructura Jerárquica de un Sistema Operativo
• THE (DIJKSTRA).
2.12. Migración del núcleo a microcódigo:
2.13 Rutinas, corrutinas, procesos e hilos
2.13.1. Rutina
• Una rutina es un conjunto de estatutos y estructuras de datos propias.

• Tiene la característica de ser una parte de código PASIVA, es decir, solo se ejecuta
cuando se llama a través de un CALL.
• Cada vez que se llama es ejecutada desde su primer instrucción.
• Al momento de ser llamada sólo se guardan parte de los registros del procesador,
normalmente el apuntador del programa.
2.13.2. Corrutina
• Es un conjunto de estatutos y estructuras de datos propias.

• Es una parte de código PASIVA, pero la forma de ejecutarse no es a través de un
CALL sino a través de un TRANSFER.
• Solo la primera vez que se le transfiere el control con TRANSFER se ejecuta desde
su primer instrucción, las siguientes veces se ejecuta en la instrucción siguiente al
TRANSFER que se ejecutó en SU código.
• Cuando se ejecuta un TRANSFER se guardan TODOS los registros de la corrutina
que ejecutó el TRANSFER y se cargan los registros ANTERIORES de la corrutina
a la cual se le transfiere el CONTROL.
• El formato de la instrucción TRANSFER es: TRANSFER(ID CO) donde IDÁSO
identifica a la corrutina a la que se transfiere el control.
• Un detalle importante es que el CONTROL de cual corrutina se ejecuta depende de
ellas mismas, es decir, que el CONTROL está CODIFICADO dentro de las
corrutinas.
• La ventaja de las corrutinas es que es bastante simple el realizar una aplicación que
simule MIJLTIPROGRAMACION, el lenguaje MODULA-2 en su definición
estándar tiene contemplado el manejo de corrutinas.

2.13 RUTINAS. CORRUTINAS, PROCESOS E HILOS 27
2.13.3. Proceso
• Un proceso es un conjunto de estatutos y estructuras de datos propios.

• Es una parte de código ACTIVA, su ejecución depende de un algoritmo de
asignación del procesador y es la entidad a la que se le asignan recursos del sistema
como memoria principal y dispositivos.
• Una vez que un proceso es creado, y se le asigna procesador empieza a correr en su
primera instrucción, las siguientes veces que se le asigne procesador correrá a partir
de la instrucción en la que se BLOQUEÓ o haya sido interrumpido.
• Cuando se quita el PROCESADOR a un PROCESO se guardan TODOS sus
registros y al darle el PROCESADOR se cargan todos los registros del PROCESO
al PROCESADOR.
• Los procesos son los más utilizados debido a que las aplicaciones son más simples,
puesto que el control de la asignación del procesador no depende de ellos sino del
algoritmo de asignación del PROCESADOR.
2.13.4. Hilos
• Algunos sistemas como el OS/2, MVS. UNIX-SUN y MACH ven a los procesos
desde dos puntos de vista:
1. Como una unidad que posee recursos. A un proceso se le asigna una área de
memoria para poder correr y periódicamente se le asignan memoria y otros
dispositivos.
2. Como una unidad de despacho. Un proceso traslapa su ejecución con la de otros
procesos y puede pasar durante su vida por varios estados como LISTO,
CORRIENDO, BLOQUEADO, etc. y es despachado o planificado por el
sistema operativo.
• A la parte relativa a la UNIDAD QUE POSEE RECURSOS se le denomina
PROCESO o TAREA, mientras que a la parte de UNIDAD DE DESPACHO se le
denomina PROCESO LIGERO o simplemente HILO (Thread).
• El uso más sobresaliente del concepto de HILO es que se pueden tener múltiples
HILOS para el mismo PROCESO de forma que toma mucho menos tiempo crear
nuevos HILOS que crear un nuevo PROCESO. De este modo es más eficiente
diseñar una aplicación para correr como un solo proceso con múltiples hilos que
correr dicha aplicación como múltiples procesos.
• Otra característica atractiva de los hilos es que dado que sólo existe un proceso es
directa la compartición de datos entre los hilos, mientras que en un esquema con
múltiples procesos se requeriría la intervención del KERNEL para realizar la
compartición de datos lo que haría más lenta la aplicación.
• Un ejemplo práctico del uso de los hilos es el programa Aldus-PageMaker
corriendo bajo OS/2, este programa está diseñado con tres hilos que siempre están
activos:
1. Hilo Manejador de Eventos(Event Handling).

2. Hilo Redibujador de Pantalla(Screen Redraw).

3. Hilo de Servicio(Service) Encargado de la inicialización, Importación de datos,

Auto flujo e Impresión.
2.14. Referencias

[14], [15], [16], [17], [18], [19], [20], [21], [22], [23],[24], [13], [25], [26], [27],
[28].

Capítulo 3
Algoritmos de administración de
procesadores
En este capítulo se presentarán diversos algoritmos para controlar la asignación de

procesadores a procesos.
3.1. Objetivos de la asignación de procesadores
1. Ser justo evitando la posposición indefinida

2. Maximizar el número de procesos atendidos por unidad de tiempo.
3. Maximizar el número de usuarios que reciben tiempos de respuesta aceptables.
4. Ser predecible. Debe funcionar en forma similar al variar la carga del sistema. Los
tiempos de respuesta no deben incrementarse grandemente al incrementar el
número de procesos en el sistema.
5. Minimizar la sobrecarga (Overhead) ocasionada por el algoritmo de asignación del
CPU.
6. Balancear el uso del procesador.
7. Balancear e] tiempo de respuesta del sistema y la utilización del mismo.
8. Reforzar las prioridades en ambientes donde sea necesario, v.gr. en aplicaciones de
tiempo real.
9. Dar más prioridad a los procesos que tengan asignados los recursos importantes del
sistema.
10. Debe presentar una degradación paulatina (Graceful Degradation) al tener cargas
de trabajo grandes.
3.2. Criterios de la asignación de CPU

Debería considerarse:
29
30 CAP 3. ALGORITMOS DE ADMINISTRACIÓN DE PROCESADORES
1. La cantidad de Entrada/Salida que realizará un proceso.

2. El tipo de proceso, si es INTERACTIVO o tipo BATCH.
3. Lo urgente de la respuesta, si es tiempo real o no.
4. Prioridad de los procesos.
5. La frecuencia con la que un proceso genera FALTAS DE PAGINA( Si mayor
frecuencia menor prioridad).
6. El número de veces que se le ha asignado el procesador a un proceso.
7. El tiempo de ejecución acumulado de un proceso.
8. El tiempo estimado de ejecución que le falta a un proceso.
3.3. Asignación preemptive vs. no-preemptive
En el caso de los sistemas con adquisición por prioridad (PREEMPTIVE), el

procesador es asignado al proceso de mayor prioridad, sin importar si se le acababa de
asignar el procesador a un proceso de menor prioridad.
En el caso de los sistemas que no manejan adquisición por prioridad el procesador
le es quitado a un proceso solo cuando él se bloquea o termina.
3.4. Manejo de quantum
Para evitar que un proceso monopolice el procesador, en muchos sistemas se utiliza

un temporizador de QUANTUMS que genera una interrupción periódica. Cada vez que
ocurre esta interrupción se le quita el procesador que está actualmente corriendo y se le
otorga al siguiente proceso de la cola de listo, cuando ocurre esto se dice que se dió un
cambio de contexto.
3.5. Prioridad
La prioridad puede tener características estáticas y dinámicas:
• CARACTERÍSTICAS ESTÁTICAS
- Tamaño de código.
- Tiempo estimado de ejecución.
- Cantidad de Entrada / salida estimada.
• CARACTERÍSTICAS DINÁMICAS
- Tiempo acumulado de ejecución.

- Cantidad de recursos que tenga algún proceso.
- Número de veces que se le ha otorgado el PROCESADOR a algún proceso.
- Tiempo estimado faltante para terminar de un proceso.
3.9. ASIGNACIÓN DE CPU SHORTEST REMAINING TIME FIRST 31
Figura 3.1. Asignación de CPU FIFO.
3.6. Asignación de CPU FIFO
Está es la disciplina más sencilla, el procesador es asignado en orden secuencial de

entrada al sistema, el procesador se le quita a un proceso hasta que termina. Esto se
ilustra en la figura 3.1.
3.7. Asignación de CPU Round Robin
El procesador es asignado a los diferentes procesos en rebanaditas de tiempo

llamadas quantum. Al terminarse el quantum de un proceso, este es insertado al final
de la cola de listo. Si el proceso termina antes de terminar su quantum, o al terminar
esté, el proceso libera el CPU y se le otorga el CPU al siguiente proceso de la cola de
listo.
El tamaño del quantum no debe ser tan pequeño que se acerque al tiempo de
cambio de contexto, ni tan grande que se acerque al tiempo de ejecución de un proceso.
Esto se ilustra en la figura 3.2.
Figura 3.2. Asignación de CPU Round Robin.
3.8. Asignación de CPU Shortes Job First (SJF)

Este algoritmo es de tipo NO-PREEMPTIVE en la que el PROCESADOR se le
otorga al proceso con menor tiempo estimado de ejecución. El poder estimar el tiempo
de ejecución de un proceso no es fácil. Tomando como equivalente el tamaño del
código y el tiempo de ejecución podría ocurrir que en un proceso de tamaño de código
pequeño sea muy iterativo y un proceso de tamaño de código grande no tenga
iteraciones.
3.9. Asignación de CPU Shortest Remaining Time First
Es similar al algoritmo anterior pero es de tipo PREEMPTIVE. Tiene gran

sobrecarga puesto que se debe ir registrando el tiempo de ejecución de cada proceso.
3.10. Asignación de CPU de colas con retroalimentación multiniveles
Es un algoritmo de tipo PREEMPTIVE entre las colas de diferente prioridad. En

todas las colas menos la última la atención es en forma FlEO, y en la última es
ROUND ROBIN. Un proceso al entrar ingresa a la primer cola y conforme avanza en
su ejecución pasa a las colas de menor prioridad si acaso no termina antes.
Tiene la ventaja que los procesos pequeños terminan normalmente antes de llegar a
la última cola, y los procesos grandes al llegar a la última cola ya avanzaron en su
ejecución.
El procesador se le asigna al primer proceso de la cola de más alta prioridad que no
esté vacía.
Permite clasificar fácilmente a los procesos conforme avanzan en su ejecución.
Una variación es permitir varias vueltas en las primeras colas.
Este algoritmo se ilustra en la figura 3.3.
Figura 3.3. Colas con retroalimentación multi-niveles.
3.11. Asignación de CPU Selfish Round Robin (SRR)
Clasifica a los procesos en NUEVOS y ACEPTADOS. Los procesos NUEVOS

tienen que esperar a que tengan la prioridad de un proceso aceptado para convenirse en
ACEPTADO y competir por los QUANTUMS del procesador. Los procesos aceptados
son

3.14. ASIGNACIÓN DE CPU BASADOSEN PRIORIDADES EXTERNAS 33
manejados en forma ROUND ROBIN. La prioridad de los procesos nuevos se

incrementa con un razón a. La prioridad de los procesos aceptados se incrementa con
una razón b. Si todos los procesos aceptados terminan se acepta al proceso nuevo de
mayor prioridad.
Este método se puede implementar fácilmente si se considera que todos los
procesos aceptados tienen la misma prioridad.
Algunos casos interesantes son:
1. Si b / a = 0, es decir b =0. Todos los procesos son aceptados inmediatamente y el
algoritmo se convierte en Round Robin.
2. Si b / a _ 1. Un proceso nuevo no se acepta hasta que los procesos aceptados
terminan, dándose un algoritmo similar a FlFO.
3. Si 0 < b / a < 1. Los procesos aceptados son egoístas pero llega un momento en que
los procesos nuevos pasan a ser procesos aceptados y no necesariamente ocurre
esto hasta que terminen todos los procesos aceptados.
3.12. Asignación de CPU con algoritmos híbridos
Los algoritmos anteriores pueden ser combinados para crear nuevos v.g.:
1. En las colas con retroalimentación multiniveles, se podría manejar la última cola
como FlFO para reducir el tiempo perdido por CAMBIOS DE CONTEXTO.
2. Manejar los procesos en forma Round Robin por un número determinado de
quantum y después manejar los procesos en forma FIFO.
3. Manejar colas de diferente prioridad cada una de ellas en forma ROUND ROBIN o
FlFO.
3.13. Asignación de CPU dependientes del estado
1. Ajustar el tamaño del quantum en el algoritmo Round Robin en función del número
de procesos en la cola de LISTOS. De este modo sería más justo el tiempo otorgado
a cada proceso. Se debe cuidar que si hay demasiados procesos en la cola de listos
no se den QUANTUMS muy pequeños. En el caso de que sólo exista un proceso en
la cola de listos se evitarían cambios de contexto.
2. Dar un quantum adicional al proceso que está corriendo cuando un nuevo proceso
entra al sistema.
3. Algunas versiones del sistema operativo UNIX utilizan el siguiente método: Cada
segundo se calcula la prioridad de cada proceso. La prioridad de un proceso es
función de la prioridad dada inicialmente y el tiempo de CPU dado recientemente
al proceso. Entre más tiempo de CPU se le ha dado recientemente a un proceso es
menor su prioridad.
3.14. Asignación de CPU basados en prioridades externas
1. Usar Round Robin pero el tamaño del quantum es particular para cada proceso y el
tamaño de él depende de la prioridad del proceso.

2. Se da el siguiente Quantum al proceso que haya “sufrido” más, el sufrimiento se

mide
por:
• Tiempo de espera de un proceso.
• Número de veces que se le ha quitado el CPU a un proceso.
3. Se tiene el compromiso de un tiempo máximo de respuesta.
3.15. Referencias

[3], [14], [29], [30], [18], [31], [32], [l0], [33], [34], [11]. [26], [27], [35], [36],
[37], [25].

Capítulo 4
Administración de
Memoria Real
4.1. Introducción
Por almacenamiento real se entiende a la memoria principal que en las

computadoras actuales se implementa a través de memorias de semiconductores y
dicha memoria es accesible directamente por el CPU.
El almacenamiento virtual, como se verá en el capítulo 8, es la capacidad de
accesar más memoria que la principal.
4.2. Organización
La memoria principal es un recurso muy costoso e importante, razón por la cual ha

habido muchos estudios para optimizar su uso.
Algunas preguntas importantes en la organización son:
+ ¿Localizaremos a un solo usuario o a varios usuarios en memoria principal al

mismo tiempo?
+ Si hay varios usuarios al mismo tiempo, ¿ Les asignaremos la misma cantidad de
memoria a cada uno o les asignaremos “PARTICIONES” de tamaño diferente a cada
uno?
+ ¿Particionaremos la memoria principal en forma dinámica o en forma estática?
+ ¿Requerimos que los procesos de usuario sean diseñados para correr en una
partición específica o pueden correr en cualquier partición en la que quepan?
+ ¿Se requiere que un proceso sea localizado en un solo bloque contiguo en
memoria principal o puede ser dividido en varios bloques discontiguos?
35

36 CAP 4. ADMINISTRACIÓN DE MEMORIA REAL
4.3. Administración del almacenamiento
Independientemente de qué práctica se escoja para la organización del

almacenamiento con respecto a la administración del mismo debemos cuestionamos:
• ¿Cuándo tomaremos un nuevo programa para cargarlo en memoria?

• ¿Se esperará a que se requiera cargar un programa o se tratará de anticipar las
demandas?
• ¿Cargaremos los programas tratando de minimizar: espacio desperdiciado o tiempo
requerido para ejecución?
4.4. Jerarquía de almacenamiento
En los 50’s y 60’s la memoria principal estaba constituida por memorias de núcleos
magnéticos muy costosas, por lo cual era indispensable diseñar un sistema
computacional con el mínimo tamaño requerido.
Por lo tanto era necesario sólo conservar en memoria principal el código y datos
estrictamente necesario y lo demás en memoria secundaria.
La memoria secundaria era de mayor densidad, con un costo por bit menor, pero
con tiempos de acceso mayores que la memoria principal.
Teniendo la jerarquía ilustrada en la figura 4.1.
Figura 4.1. Jerarquía de Almacenamiento de Memoria.
En los 60’s fue muy clara la necesidad de que la jerarquía de almacenamiento

incluyera un nivel adicional con cambios sustanciales en el desempeño de los sistemas
computacionales. Este nuevo nivel fue la memoria CACHE, que iría entre el CPU y la
memoria principal. La memoria CACHE obviamente es más cara, de menos capacidad
y más rápida que la memoria principal. El esquema de jerarquía de memoria usando
memoria cache es ilustrado en la figura 4.2.
4.6.ASIGNACIÓN DE ALMACENAMIENTO CONTIGUO VS. NO-CONTIGUO 37
Figura 4.2. Jerarquía de memoria usando memoria cache.
4.5. Estrategias de Administración de Almacenamiento.

1. Estrategias de FETCH.
• Por demanda.
• Anticipatoria.
2. Estrategias de localización.
3. Estrategias de reemplazo.
4.5.1. Estrategias de Fetch

.Se encargan de definir el “CUANDO” traer la siguiente parte de información a
memoria principal. La estrategia más común es por demanda, es decir, que una parte de
información se trae hasta que se requiere. Actualmente se investiga sobre políticas
ANTICIPATORIAS.
4.5.2. Estrategias de localización
Se refiere a DONDE dentro de memoria principal localizar un programa. FIRST

FIT, BEST FIT, WORST FIT, BUDDY FIT, FIBONACCI FIT).
4.5.3. Estrategias de reemplazo
Se relaciona con la determinación de qué parte de un programa QUITAR para

poder poner una nueva parte.
4.6. Asignación de Almacenamiento Contiguo vs. No-Contiguo
Los primeros sistemas de cómputo requerían la asignación de almacenamiento

contiguo, es decir que un programa tenía que ocupar un bloque de almacenamiento con
localidades contiguas, mas sin embargo se vio más tarde la utilidad del
almacenamiento NO CONTIGUO.
En la localización NO CONTIGUA un programa es dividido en varios bloques o
segmentos que pueden ser localizados dentro del espacio de almacenamiento en
bloques

de almacenamiento no necesariamente contiguos. Esto permite una mejor utilización

del espacio de almacenamiento pero complica la labor del sistema operativo.
4.6.1. Asignación de almacenamiento contiguo a un solo usuario
En los primeros sistemas computacionales todo el sistema de cómputo estaba

dedicado a un solo usuario, limitando a que los programas que fuera a correr cupieran
en el espacio disponible, la organización de memoria resultante es ilustrada en la figura
4.3.
La única forma de poder correr programas más grandes que el espacio disponible
fue el manejo de OVERLAYS. Dentro del manejo de OVERLAYS, dos o más áreas de
un programa pueden ocupar el mismo espacio de almacenamiento en diferente tiempo.
El manejo de OVERLAYS requiere una planeación muy cuidadosa y se realiza
manualmente, pues el manejo automático es complejo, un esquema típico de manejo de
overlays es ilustrado en la figura 4.4.
4.6.2. Protección en sistemas de un solo usuario
Para evitar que un programa de usuario que esté funcionando mal o “malicioso”
dañe el sistema operativo, se pueden verificar las direcciones generadas por el
programa y no permitir accesos si las direcciones corresponden al sistema operativo.
Si el usuario requiere accesar parte del sistema operativo se puede controlar a través
de un llamado al supervisor (SUPERVISOR CALL).
La protección de almacenamiento con asignación de almacenamiento contiguo a un
solo usuario es realizado a través del uso de registros límite según se ilustra en la figura
4.5.
Sistemas
operativo
Usuario
No usado
Figura 4.3. Asignación de almacenamiento contiguo a un solo usuario.

4.7. SISTEMAS TIPO BATCH 39
-1 Carga la fase de inicialización y corre

-2 Carga la fase de procedimiento en b y corre
-3 Carga la fase de salida de b y corre
Figura 4.4 Estructura de manejos de overlays
0
Sistemas
a operativo
CPU
a
Usuario
Registro limite
b
No usado
c
Figura 4.5. Esquema de protección en un sistema con un solo usuario y almacenamiento contiguo.
4.7. Sistemas Tipo Batch

En los primeros años de los 60’s los sistemas más novedosos eran los de tipo Batch
en los cuales el tiempo requerido para poner a correr otro proceso se redujo a través del
uso de PROCESADORES SATÉLITE.
Los procesadores satélite podían preparar “tandas” de procesos a ejecutarse en la
computadora central, leyendo las tarjetas perforadas del código de procesos y
pasándolas a

CINTA MAGNÉTICA. De ésta forma el tiempo ocioso de la computadora central se

redujo grandemente.
4.8. Multiprogramación de Partición Fija
Aún con los sistemas tipo BATCH los sistemas de cómputo eran subutilizados
(ESTO SIN TOMAR EN CUENTA LO INJUSTO DE LOS TIEMPOS DE ESPERA)
pues un proceso que requiriera una operación de EIS forzaba al procesador a estar
ocioso hasta que estuviera completa dicha operación, según se ilustra en la figura 4.6.
En el caso de que una aplicación no realice operaciones de entrada / salida o sean muy
pocas se tienen un uso muy eficiente del CPU, esto es típico de aplicaciones “number-
crunching” o intensivas en cómputo.
Figura 4.6. Esquema de uso de CPU al realizar operaciones de entrada / salida.
Fue entonces cuando se decidió el implementar un sistema en el cual en forma

simultánea varios procesos compitieran por los recursos del sistema; a este sistema se
le conoció como de: MULTIPROGRAMACIÓN.
De ésta forma un proceso podría estar esperando la terminación de una operación
de ENTRADA, otro proceso la terminación de una operación de SALIDA y otro
usando el CPU.
Esto requirió que varios procesos pudieran estar simultáneamente en memoria
principal para poder reducir los tiempos de CAMBIO DE CONTEXTO (CONTEXT
SWITCHING).
4.9. Multiprogramación de partición fija, traducción y cargado absoluto
En este tipo de sistemas se definían un conjunto de particiones de la memoria

principal, de ésta forma podría haber al mismo tiempo diferentes procesos en diferentes
particiones. Desde el momento de compilación o ensamblado se definía la partición
donde debía correr cada proceso. Este esquema es ilustrado en la figura 4.7. De esta
forma podría haber particiones desocupadas y procesos esperando usar una partición
donde esté localizado un proceso, este problema es ilustrado en la figura 4.8.

4.10. MULTIPROGRAMACIÓN DE PARTICIÓN FIJA CON CARGADO 41
Figura 4.7. Esquema de multiprogramación fija y cargado absoluto.
Figura 4.8. Problema en un esquema de multiprogramación fija con cargado absoluto.

Figura 4.9. Esquema de multiprogramación de partición fija relocalizable.
4.10. Multiprogramación de partición fija con cargado y traducción relocalizable
Los procesos se localizan en alguna partición libre donde quepan. Un proceso

puede empezar a correr tan pronto como este al frente de la única cola que se maneja
en este esquema, y exista una partición libre en la cual quepa. Esto es ilustrado en la
figura 4.9.
4.11. Protección en sistemas de multiprogramación
Requiere de la utilización de un par de registros límite. Un par de registros límite,

define el límite inferior y superior del área de memoria que es accesible a un proceso,
cuando esté corriendo en cierta partición. Este esquema es ilustrado en la figura 4.10.
Figura 4.10. Esquema de protección en un sistema de multiprogramación.
4.12. Fragmentación en Sistemas de Multiprogramación de Partición Fija
La fragmentación ocurre cuando un proceso es más pequeño que la partición a la

que. fue asignado, de esta forma se desperdicia el espacio que sobra. Ocurre también
cuando una partición no puede usarse debido a que es muy pequeña para albergar
procesos que están esperando ser cargados en memoria principal.

4.14. COMPACTACIÓN DE ALMACENAMIENTO 43
4.13. Multiprogramación de Partición Variable
Tratando de utilizar más eficientemente la memoria principal se implementaron las

PARTICIONES VARIABLES, en las que a un proceso sólo se le asigna la cantidad de
localidades de memoria que requiere, esto se ilustra en la figura 4.11. Cuando los
procesos terminan su ejecución, quedan huecos entre los espacios que están ocupados,
por lo cuál es necesario realizar la unión de huecos, los diferentes casos son ilustrados
en las figuras 4.12, 4.13, 4. 14.
Figura 4.11. Esquema de multiprogramación variable.
4.14. Compactación de Almacenamiento
Aún cuando se realice la operación de unión puede llegar a ocurrir que queden
muchos huecos no-contiguos, de forma que un proceso no quepa en ninguno de los
huecos, pero su tamaño sea menor o igual que la suma de los tamaños de los huecos.
Ante lo anterior se realiza una COMPACTACION o RECOLECCION DE
BASURA con el objeto de dejar contiguos todos los espacios ocupados y todos los
huecos, que ahora formarán un solo hueco. Este esquema es ilustrado en la figura 4.15.
Esto permitiría correr a todos los procesos posibles, pero tiene las siguientes
desventajas:

• Consume tiempo de CPU.

• Mientras se realiza la compactación nada puede hacerse.
• Involucra relocalización de procesos.
• Si la mezcla de procesos es muy dinámica, es frecuente el uso de la compactación.
S O S O S O
P A Hueco
Hueco
Hueco Hueco
P C P C P C
Hueco Hueco Hueco
P E P E P E
P F P F P F
Hueco Hueco Hueco
Figura 4.12. Ejemplo de unión de huecos hacia abajo.
S O S O S O
Hueco Hueco Hueco
P C P C P C
Hueco Hueco
Hueco
P E Hueco
P F P F P F
Hueco Hueco Hueco
Figura 4.13. Ejemplo de unión de huecos hacia arriba.

4.15. ESTRATEGIAS DE LOCALIZACIÓN DE ALMACENAMIENTO 45
S O S O S O
Hueco Hueco
P C Hueco Hueco
Hueco Hueco
P F P F P F
Hueco Hueco Hueco
Figura 4.14. Ejemplo de unión de huecos hacia ambos lados.
S O S O
P A P A
Hueco P 2
P b
P C
Hueco
P C
Hueco
Hueco
Figura 4.15. Operación de un esquema de recolección de basura (garbage collection).
4.15. Estrategias de Localización de Almacenamiento
Permiten determinar “DONDE” en la memoria principal localizar un proceso
4.15.1. Estrategia Best Fit
Localiza a un proceso en el lugar que menos espacio desperdicie. Esto se ilustra en

la figura 4.16.

Requerimiento
4 K
asigna
Sistema operativo
Hueco 16 K
P A
Hueco 14 K
P B
Hueco 5 K
P C
Hueco 30 K
Figura 4.16. Localización de almacenamiento utilizando Best Fit.

Sistema operativo
Requerimiento Hueco 16 K
4 K P A
asigna Hueco 14 K
P B
Hueco 5 K
P C
Hueco 30 K
Figura 4.17. Localización de almacenamiento utilizando First Fit.
4.15.2. Estrategia First Fit

Localiza a un proceso en el primer espacio en el que quepa. Esto se ilustra en la
figura 4.17.
4.15.3. Worst Fit

Localiza al proceso en el espacio más grande posible. Esto es ilustrado en la figura
4.18.
Sistema operativo
Requerimiento Hueco 16 K
4 K P A
asigna Hueco 14 K
P B
Hueco 5 K
P C
Hueco 30 K
Figura 4.18. Localización de almacenamiento usando Worst Fit.
4.15.4. Estrategia Buddy Fit
Todos los bloques, sean libres u ocupados, son de tamaño 2k.

4.19. MULTIPROGRAMACIÓN CON INTERCAMBIO DE PROCESOS EN ALMACENAMIENTO 47
De ésta forma si un proceso es de tamaño X se le asignará un bloque de tamaño

2[log 2X], si existe un bloque libre de ese tamaño se asigna y si no se crea un bloque
de ese tamaño por particiones de algún bloque de tamaño inferior.
La unión de huecos sólo es válida para huecos del mismo tamaño y que sean
resultado la misma partición o corte, formando un hueco del doble del tamaño de
sus partes. Para saber si dos huecos del mismo tamaño son parejas o no:
Si d1 = dirección de un bloque
d2 = dirección del otro bloque
t = tamaño del bloque
ĺ Los bloques que están en d1 y d2 de tamaño t son parejas Si
d1=d2+t o d2=d1+ t o t=d1 + d2.
4.15.5. Estrategia Fibonacci Fit

La estrategia BUDDY FIT es un caso especial de ésta estrategia. Se basa en la
asignación de bloques cuyo tamaño es un número de fibonacci. La unión de huecos se
realiza sólo entre bloques contiguos y que sean números de fibonacci contiguos los
tamaños de los bloques.
4.16. Fragmentación Interna
Cuando de un bloque se desperdicia algo.
4.17. Fragmentación Externa
Cuando hay muchos huecos pequeños.
4.18. Comparación de estrategias de localización
En la tabla 4.1 se presenta una comparación de las diferentes estrategias de

localización.
Fragmentación Fragmentación Rapidez
interna externa
Best Baja Alta Lento
Worst Nula Baja Lento
First Media Baja Muy rápido
Buddy Alta con tamaños grandes Baja Muy rápido
Tabla 4.1. Comparación de estrategias de localización.
4.19. Multiprogramación con Intercambio de Procesos en Almacenamiento
En este tipo de sistemas un proceso puede pasar de memoria secundaria a

memoria principal y viceversa varias veces antes de terminar su ejecución. La razón
puede ser por
manejo de QUANTUM, espera de un evento de E/S, etc. Este tipo de sistemas

prácticamente dieron origen a los sistemas de manejo de memoria virtual.
4.20.Referencias

[38], [39], [18], [40], [21], [33], [41], [26], [27], [24], [42], [35], [43], [36], [37].

Capítulo 5
Memoria virtual
El termino memoria virtual está asociado a la habilidad de poder accesar un
espacio de almacenamiento mayor que el espacio de almacenamiento principal de un
sistema computacional.
Este concepto apareció por primera vez en el sistema computacional Atlas
construído en la universidad de Manchester en 1960.
Los métodos más comunes para el manejo de memoria virtual son:
• segmentación
• paginación
• segmentación con paginación
• La evolución de los sistemas de almacenamiento es ilustrada en la figura 5.1.
Real Real Virtual

Sistemas Sistemas Multiprogramación Almacenamiento real Multiprogramación Almacenamiento Virtual
Dedicados
Monosaurio
Multiprogramación Multiprogramación Paginación Segmentación Segmentación
Partición Fija Partición variable Paginación
Absoluto Relocalizable
Tabla 5.l Evolución de las Organizaciones de Almacenamiento.
5.1. Conceptos básicos de almacenamiento virtual

La clave del concepto de almacenamiento virtual está en desasociar las
direcciones referenciadas por un proceso en ejecución de las direcciones disponibles
en almacenamiento primario.
El rango de direcciones virtuales V necesita un mecanismo de mapeo al rango de
direcciones reales R. Esto es ilustrado en la figura 5.1.
49

50 CAP 5. MEMORIA VIRTUAL
Almacenamiento virtual Almacenamiento real
Figura 5.l. Mapeo de las direcciones virtuales a las direcciones reales.
Algunos sistemas utilizan como mecanismo de mapeo ¡a traducción dinámica de

direcciones (DAT = Dynamic Address Translation) en los que existe la contigüidad
artificial, es decir, direcciones virtuales contiguas no necesariamente corresponden a
direcciones reales contiguas. Esto se ilustra en la figura 5.2.
Almacenamiento
Mecanismo real
de mapeo de
Almacenamiento
direcciones
virtual
Figura 5.2. Traducción dinámica de direcciones.

5.5. CONCEPTOS BÁSICOS DE PAGINACIÓN 51
5.2. Organización de Almacenamiento Multiniveles
Algunas computadoras soportan 3 niveles en la jerarquía de almacenamiento,

aunque algunas no soportan la memoria Caché. Esto se ilustra en la figura 5.3. Debido
a que procesos muy grandes pueden estar corriendo concurrentemente en memoria
principal habrá porciones de cada proceso.
Figura 5.3. Arquitectura de tres niveles en la organización de la memoria.
5.3. Mapeo de Bloques
Si el mapeo de direcciones virtuales a reales fuera en base a bytes o palabras, el

espacio requerido para almacenar la información del mapeo ocupada más espacio que
la información que se mapea.
Si el mapeo fuera en base a bloques de tamaño muy grande se requeriría muy poco
espacio para almacenar la información del mapeo, pero el tiempo requerido para
realizar transferencias sería muy grande y limitaría el número de procesos que podrían
estar corriendo.
Si los bloques son de tamaño fijo se habla de un sistema de paginación.
Si los bloques son de tamaño variable se habla de un sistema de segmentación.
Si los bloques son de tamaño variable pero en múltiplos de páginas se habla de un
sistema de segmentación con paginación.
5.4. Direcciones de Mapeo de Bloques
Las direcciones en un sistema de mapeo de bloques son bidimensionales. De ésta

forma una dirección virtual será: y = (b, d)
donde: b especifica el número de bloque y d el desplazamiento dentro del bloque
especificado. Este esquema es ilustrado en la figura 5.4.
5.5. Conceptos Básicos de Paginación
Una dirección virtual en un sistema de paginación consiste de un par ordenado:

V = (p, d) donde p es el número de página y 1 es el desplazamiento dentro de la
página.

52 CAP. 5. MEMORIA VIRTUAL
Figura 5.4. Traducción de direcciones virtuales con mapeo de bloques.
Las páginas son transferidas de / a disco a / de memoria real usando marcos de

página de memoria principal. De ésta forma:
• El marco de página cero ocupa direcciones de 0 a X - 1 donde X es el tamaño de
página
• El marco de página uno ocupa direcciones de X a 2X - 1
• El marco de página i ocupa direcciones de iX a (i + 1)X - 1
Como no es posible tener todas las páginas disponibles en memoria principal a un
tiempo se maneja una estructura de datos que contiene:
• Un bit de Residencia
• Dirección en el almacenamiento secundario si la página no está en memoria
principal.
• Número de marco de página en almacenamiento real. Esto se ilustra en la figura
5.5.

5.7. TRADUCCIÓN DE DIRECCIONES DE PAGINACIÓN POR MAPEO ASOCIATIVO 53
Figura 5.5. Estructura de datos para manejo de paginación.
Figura 5.6. Traducción de direcciones por mapeo directo
5.6. Traducción de Direcciones de Paginación por Mapeo Directo
Este esquema se ilustra en la figura 5.6.

Figura 5.7. Traducción de Direcciones de Paginación por Mapeo Asociativo
5.7. Traducción de Direcciones de Paginación por Mapeo Asociativo
5.8. Traducción de Direcciones de Paginación Combinando Mapeo Asociativo y

Directo
5.9. Compartición en un Sistema de Paginación
Para evitar duplicar o n-plicar páginas en memoria principal se pueden compartir

páginas entre varios procesos, teniendo presente los problemas que pueden surgir
(lectores / escritores).
Al código que puede ser ejecutado concurrentemente por varios procesos se le
llama: código puro o código reentrante (Vgr. Editor).
5.10. Segmentación
La traducción de direcciones en un sistema con segmentación puede ser hecha en

forma similiar como se realiza en los sistemas de paginación. El control de acceso
dentro de un sistema de segmentación permite controlar:

5.10. SEGMENTACIÓN 55
Figura 5.8. Traducción de Direcciones de Paginación Combinando Mapeo Asociativo y Directo.
• lectura
• escritura
• ejecución
• agregado.
Los modos de control de acceso más comunes son:
R W E Comentario
0 0 0 No se permite acceso.
0 0 1 Solo ejecución.
0 1 0 No tiene sentido solo permitir escribir.
0 1 1 Ejecución si no se puede leer.???
1 0 0 Solo lectura.
1 0 1 Lectura y ejecución.
1 1 0 Lectura / escritura.
1 1 1 Acceso irrestricto.
Tabla 5.2 Control de acceso.

Una entrada de la tabla de segmentos contiene: r = bit de residencia; a = dirección

de almacenamiento secundario; permisos R, W, E y de Agregado; y S’ = Dirección
base del segmento en memoria principal (si acaso está).
La compartición de segmentos es más fácil y flexible que la compartición de
páginas, pues al crecer o disminuir un espacio de memoria en la segmentación sigue
siendo un segmento, pero en la paginación varía el número de páginas.
5.11. Sistemas de Paginación con Segmentación
En éstos sistemas los segmentos son de tamaño variable, pero en múltiplos de

páginas. De ésta forma una dirección virtual es vista por:
V = (s, p, d)
s = número de segmento
p = número dentro del segmento
d = desplazamiento dentro de la página.
Este esquema se ilustra en la figura 5.9. Un esquema completo que ilustra varios
procesos bajo un esquema de paginación con segmentación es dado en la figura 5.10.
5.12. Administración del Almacenamiento Virtual
5.12.1. Estrategias de Administración de Almacenamiento Virtual
Estrategias de Búsqueda
Se refieren a “cuándo” traer una página de almacenamiento secundario a almacena-

miento primario. Las opciones básicas son:
• Demanda: Espera hasta que sea referenciado un segmento o página para traerla.
• Anticipatoria: Intenta determinar a priori la página o segmento que será
referenciado para traerlo.
Estrategias de Localización
Se refiere a “dónde” localizar dentro de memoria principal la página o segmento
que se trae de memoria secundaria.
Estrategias de Reemplazo
Se refiere a “cuál” segmento o página desplazar de memoria principal cuando no
haya espacio para localizar un segmento o página que es traído de memoria secundaria.

5.12. ADMINISTRACIÓN DEL ALMACENAMIENTO VIRTUAL 57
Figura 5.9. Esquema de paginación con segmentación.
5.12.2. El Principio de Optimalidad
Establece que para obtener un desempeño óptimo la página que debe reemplazarse
es la que no será usada por el tiempo más largo en el futuro. Claro que esta política es
prácticamente irrealizable pues los sistemas operativos no cuentan con una “bola de
cristal” infalible.
5.12.3. Reemplazo de Página Aleatorio
La página a ser reemplazada se determina usando un número aleatorio. El esquema

es muy simple pero se usa rara vez pues incluso se puede estar reemplazando la
siguiente página a ser referenciada.
5.12.4. Reemplazo de Página FIFO
A cada página se le pone una estampa de tiempo, y se reemplaza la página que

tenga más tiempo en memoria principal. El problema de esta política es que una página
que es

Figura 5.10 Esquema bajo paginación / segmentación.
referenciada frecuentemente estará siendo reemplazada frecuentemente. Parecería

lógico que entre más páginas pudieran mantenerse en memoria principal la estrategia
FIFO se comportará mejor (MENOS FALTAS DE PAGINA), mas sin embargo
Belady. Nelson y Shedler han encontrado que ciertos patrones de referencia de páginas
ocasionan más faltas de página al incrementarse el número de páginas en memoria
principal; a este fenómeno se le denomina la ANOMALIA DE REEMPLAZO DE
PAGINAS FIFO y es ilustrada en la tabla 5.3.
5.12.5. Reemplazo de Página Menos Recientemente Usada (LRU)
La página a ser reemplazada es aquélla que no ha sido usada por el tiempo más
largo. La Heurística de esta política es que: “ El pasado reciente es un buen indicador
del futuro cercano ‘ .Esta política requiere que a cada página se le ponga una estampa
de tiempo

Página Resultado 3 pp Resultado 4 pp

Referenciada
A Falta A – – Falta A – – –
B Falta B A – Falta B A – –
C Falta C B A Falta C B A –
D Falta D C D Falta D C B A
A Falta A D C No Falta D C B A
B Falta B A D No Falta D C B A
E Falta E B A Falta E D C B
A No Falta E B A Falta A E D C
B No Falta E B A Falta B A E D
C Falta C E B Falta C B A E
D Falta D C E Falta D C B A
E No Falta D C E Falta E D C B
3 No Faltas 2 No Faltas
Tabla 5.3 Anomalía de reemplazo de página FIFO.
cada vez que es referenciada, lo cual es un gran overhead; por esta razón se
implementan algunas estrategias que se aproximan a la LRU. Esta política podría
funcionar muy mal si se estuviera ejecutando un lazo donde se requieran muchas
páginas.
5.12.6. Reemplazo de Página Menos Frecuentemente Usada (LFU)
La página a reemplazar es la que es referenciada menos intensamente. Intenta

acercarse a la política LRU. Padece del problema de que las páginas “nuevas” son las
que menos frecuentemente se han usado y son las que serían reemplazadas, pero existe
el problema de que quizás sean las que serán usadas enseguida.
5.12.7. Reemplazo de Página No Usada Recientemente(NUR)
Es una aproximación a la estrategia LRU. La Heurística utilizada es que las

páginas no usadas recientemente es improbable que se usen en un futuro cercano y por
lo tanto son las que deberían reemplazarse. Utiliza por HW 2 bits adicionales por cada
página: un bit de referencia y un bit de modificación. Funciona de la siguiente manera:
• Todos los bits de referencia de todas las páginas se ponen en cero.
• Si se referencia una página su bit de referencia es puesto en uno.
• Inicialmente todos los bits de modificación se ponen en cero.
• Si se modifica una página su bit de modificación es puesto en uno.
Cuando se va a reemplazar una página tratamos de encontrar una página que no ha
sido referenciada, si no se encuentra ninguna buscaremos una página que haya sido
referenciada pero no-modificada y sino la página a ser reemplazada será referenciada y
modificada. Para poder continuar con el anterior esquema periódicamente se ponen en
cero los bits de referencia de todas las páginas. Esto se indica en la tabla 5.4 en donde
el incremento de la probabilidad de reemplazo se incrementa de renglón en renglón.

Bit de referencia Bit modificado

0 0
0 1
1 0
1 1
Tabla 5.4 Bits para el esquema de reemplazo de página (NUR).
5.12.8. Localidad
Establece que los procesos tienden a referenciar el almacenamiento en forma no-
uniforme sobre patrones altamente localizados.
Localidad Temporal
Significa que las localidades de memoria referenciadas recientemente tienen alta

probabilidad de ser referenciadas en el futuro cercano. v.g.:
• Lazos
• Subrutinas
• Stacks
• Variables para conteo y totales.
Localidad Espacial
Significa que si se está accesando una localidad en particular es muy probable que
los siguientes accesos están cerca del lugar del anterior acceso. v.g.
• Recorrido de Arreglos.
• Ejecución de Código Secuencial.
• La tendencia de localizar variables relacionadas juntas.
5.12.9. Conjuntos de Trabajo (Working Sets)
Denning desarrollé una vista de la actividad de un programa llamada: la teoría de

comportamiento de un programa basado en el conjunto de trabajo. Un conjunto de
trabajo es la colección de páginas que un proceso está referenciado activamente.
Denning sostenía que para que un programa corriera eficientemente su “conjunto de
trabajo” debería ser mantenido en memoria principal, o de otra forma se daría un efecto
llamado thrashing que se da cuando hay un número excesivo de faltas de página.
De esta forma La decisión de aceptar un nuevo proceso en el sistema debería de
estar sustentada por la existencia de suficiente espacio en memoria principal para el
“conjunto de trabajo” del nuevo proceso.
El conjunto de trabajo de páginas de un proceso en el tiempo t W(t, w) es el
conjunto de páginas referenciadas por el proceso en el intervalo t — w a
W es conocida como el tamaño de ventana del conjunto de trabajo, y la definición
de w afecta grandemente el tamaño del conjunto de trabajo como se ilustra en la
gráfica. El

conjunto de trabajo real de un proceso es el conjunto de páginas que deben estar en

memoria principal para que un proceso se ejecute eficientemente. Las páginas
referenciadas por el proceso durante este intervalo de tiempo constituyen el “conjunto
de trabajo” (working set) del proceso W(t, w).
Los conjuntos de trabajo cambian conforme se ejecuta un proceso. Se debe tomar
en cuenta que:
“los conjuntos de trabajo son transitorios y el siguiente conjunto de trabajo de un
proceso puede diferir substancialmente del anterior conjunto de trabajo”. De otra
forma se podrían otorgar conjuntos de trabajo muy grandes y el sistema experimentaría
thrashing.
5.12.10. Paginación por Demanda
La justificación de esto:
• Los resultados de la “computabilidad” nos dicen que la trayectoria de ejecución de

un programa no puede ser descrita con exactitud, por lo que una estrategia
anticipatoria no funcionará adecuadamente.
• Las únicas páginas que son traídas a memoria principal son las que realmente se
necesitan.
• La estrategia anticipatoria tiene gran overhead para el cálculo de qué página traer y
la de demanda no.
5.12.11. Paginación Anticipatoria
El bajo costo de la memoria principal podría hacer más atractivos los sistemas con
paginación anticipatoria, pues el costo de “malas” decisiones será mínimo y el
beneficio de las “buenas” decisiones daría lugar a una ejecución más rápida de los
procesos.
5.12.12. Liberación de Páginas
La idea es que los compiladores y sistemas operativos pudieran detectar cuando una
página ya no se necesita y liberarla, de esta forma los conjuntos de trabajo no
experimentarían grandes aumentos y podría mantenerse al mínimo el espacio de
memoria principal utilizado, pudiendo soportar mayor número de procesos.
5.12.13. Tamaño de Página

Consideraciones para seleccionar un tamaño de página adecuado:
• Si el tamaño de página es muy pequeño, las tablas de página serán muy grandes y
se requerirá mucho espacio para ellas. A esto se le llama fragmentación de tabla.
• Si el tamaño de página es muy grande, sólo cabrán en memoria principal unas
cuantas y se tendrán datos que realmente no serán referenciados.
• Si se quiere minimizar 110 parecería lógico tener páginas de mayor tamaño.
• Como los programas exhiben localidad de referencia y ésta es pequeña, entonces
parecería lógico tener páginas pequeñas.

62 CAR 5. MEMORIA VIRTUAL
• Si tratáramos de reducir la fragmentación interna el tamaño de página tendría que

ser más pequeño.
Típicamente el tamaño de página varia de 512 a 4096 palabras.
5.12.14. Comportamiento de un Programa Bajo Paginación
Cuando un proceso empieza a correr referencia rápidamente la mayor parte de sus

páginas, pero conforme pasa el tiempo, la razón de aumento de páginas referenciadas
disminuye.
5.13. Referencias
Para profundizaren el manejo de memoria virtual se recomiendan las siguientes
lecturas:
[38], [39], [18], [40], [33], [41], [26], [27], [24], [42], [35], [43], [36], [37], [44].

Capítulo 6
Sincronización y
comunicación de procesos
En este capítulo se verán diversos mecanismos de control de concurrencia, se tratan
ampliamente diversos mecanismos para realizar la sincronización y comunicación entre
procesos cooperativos y la solución de problemas de concurrencia clásicos.
6.1. Concurrencia de procesos
Dos procesos son concurrentes si el inicio de uno de ellos ocurre antes de la

terminación del otro, es decir, la ejecución de los procesos se traslapa en el tiempo.
En un sentido estricto la concurrencia sólo se puede dar en un sistema que conste de
más de una unidad de procesamiento.
La concurrencia de procesos es muy útil para incrementar la eficiencia y utilización
de los sistemas de cómputo.
Es una labor difícil determinar qué actividades pueden hacerse en forma
concurrente y cuáles en forma secuencial para maximizar eficiencia.
6.2. Suma de dos Matrices
Si deseamos sumar dos matrices, podemos desarrollar una versión paralela más
eficiente que una versión secuencial.
63

64 CAR 6. SINCRONIZACIÓN Y COMUNICACIÓN DE PROCESOS
La versión paralela se podría expresar como:

PARBEGIN
C[1,1] := A[1, 1] + B[1,1];
C[1, 2] := A[1, 2] + B[1,2];
C[2, 1] := A[2, 1] + B[2,1];
C[2, 2] := A[2, 2] + B[2,2];
PAREND.
Los enunciados PARBEGIN y PAREND nos sirven para indicar que los estatutos
contenidos entre ellos pueden ejecutarse en forma paralela o concurrente.
También se utilizan los enunciados COBEGIN y COEND para el mismo propósito.
6.3. Ecuación cuadrática
Tenemos que la ecuación cuadrática general ax2 + bx + c = O tiene como solución:
b 2 4ac
br
2a
El cálculo de las soluciones podría ser hecho de manera paralela de acuerdo al

siguiente programa
tiene como solución:
PARBEGIN
t1:= -b;
t2:=B * *2;
t3:=4* A * C;
t4:=2*A ;
PAREND.
t5:=(t2-t3)* *(0.5);
X1:=(t1 + t5) / t4;
X2:=(t1 – t5) / t4;
6.4. Problema de la actualización perdida
Supongamos que tenemos dos transacciones (A y B) las cuales se ejecutan en forma

concurrente y comparten variables.
PARBEGIN
TRANSACCION A;
TRANSACCION B;
PAREND.

6.6. ALGORITMO DE DEKKER (MEMORY INTERLOCK) 65
Transacción A Transacción B
tl Saldo A = Saldo X
t2 Saldo B = Saldo X
t3 Saldo X = Saldo A - 1000
t4 Saldo X = Saldo B -1000
Si: ti < t2 < t3 < t4 y SaldoX = 2000 en tl. El valor final de SaldoX es 1000 pero
debería ser 0.
De lo anterior nos damos cuenta que no se debe permitir el acceso indiscriminado
de procesos concurrentes a variables o recursos compartidos.
6.5. Exclusión mutua

De acuerdo al problema de la actualización perdida se observa que es necesario
controlar la ejecución concurrente de procesos surgiendo la necesidad de la exclusión
mutua.
La exclusión mutua es una regla de sincronización la cual especifica que los
accesos a variables o recursos compartidos deben hacerse de uno a la vez cuando
tenemos procesos concurrentes.
Cuando un proceso está ejecutando el código relativo al acceso de recursos o
variables compartidas se dice que está en su SECCION CRITICA.
La exclusión mutua puede ser implementada por medio de diferentes mecanismos.
6.6. Algoritmo de Dekker (Memory Interlock)

Considerando que no es posible el uso de instrucciones que manejen las
interrupciones (HABILITACION / DESHABILITACION DE INTERRUPCIONES), y
que la única característica que nos proporciona el HW son instrucciones de
almacenamiento indivisibles, resuelva el problema de exclusión mutua considerando
que la solución:
1. No debe dar lugar a la posposición indefinida
2. No debe dar lugar a una ejecución secuencial
3. No debe dar lugar a que se ejecuten las secciones críticas en forma simultánea
4. La solución debe ser independiente de la velocidad de ejecución de los procesos.
6.6.1. Algoritmo para construir un diagrama de estados de la ejecución
concurrente de procesos
Deben seguirse los siguientes pasos:

1.- Numere el código de los dos procesos
2.- Construya una tabla de la forma:
Estado actual Estado futuro
3.- Dentro del ESTADO FUTURO existirán tantas columnas como posibles
cambios de estado puede haber. v.g. si se trata de dos procesos tendremos:
66 CAP 6. SINCRONIZACIÓN Y COMUNICACIÓN DE PROCESOS
Estado actual Estado futuro

Avanza P1 Avanza P2 Avanzan ambos Avanzan ambos
En general el número de posibles columnas será: 2i donde i indica el número de

procesos. Pero como el caso de No Avanzan no es relevante tendremos 2 i - 1 posibles
columnas.
4.- Empiece con el estado actual 1,1 y los valores iniciales de las variables y
construya sus estados futuros.
5.- Con el siguiente estado futuro no analizado, considérelo como estado actual
y construya sus estados futuros.
6.- Continúe con el punto 5 hasta que todos los estados futuros estén
analizados.
7.- Construya la gráfica de estados.
8.- Los estados de los cuales no salen transiciones son estados de deadlock.
9.- Si se ejecutan los estatutos correspondientes a las secciones criticas hay
problemas con la solución.
6.6.2 Versión 1 de Memory Interlock
program versionone;
var processnumber: integer:

procedure processone;
begin
E1 while true do begin
E2 while processnumber=2 do;
E3 criticalsectionone;
E4 processnumber:=2;
E5 otherstuffone
end
end:
procedure processtwo;
begin
E1 while true do begin
E2 whileprocessnumber=1 do;
E3 criticalsectiontwo;
E4 processnumber:=1;
E5 otherstufftwo
end
end;
begin
processnumberl:=1;
parbegin
processone;
processtwo:
parend
end.

E. ACTUAL E. FUTURO E. FUTURO E. FUTURO

AV.PRO 1 AV. PRO 2 AV. AMBOS
1,1,1 2,1,1 1,2,1 2,2,1
2,1,1 3,1,1 2,2,1 3,2,1
1,2,1 2,2,1 1,2,1 2,2,1
221 321 221 Acceso concurrente variable
3,1,1 4,1,1 3,2,1 4,2,1
3,2,1 4,2,1 3,2,1 4,2,1
4,1,1 5,1,2 4,2,1 5,2,2
4,2,1 5,2,2 4,2,1 Acceso concurrente variable
5,1,2 1,1,2 5,2,2 1,2,2
5,2,2 1,2,2 5,3,2 1,3,2
1,1,2 2,1,2 1,2,2 2,2,2
1,2,2 2,2,2 1,3,2 2,3,2
5,3,2 1,3,2 5,4,2 1,4,2
1,3,2 2,3,2 1,4,2 2,4,2
2,1,2 2,1,2 2,2,2 2,2,2
2,3,2 2,3,2 2,4,2 2,4,2
5,4,2 1,4,2 5,5,1 1,5,1
1,4,2 2,4,2 1,5,1 2,5,1
5,5,1 1,5,1 5,1,1 1,1,1
1,5,1 2,5,1 1,1,1 2,1,1
2,5,1 3,5,1 2,1,1 3,1,1
5,1,1 1,1,1 5,2,1 1,2,1
3,5,1 4,5,1 3,1,1 4,1,1
5,2,1 1,2,1 5,2,1 1,2,1
4,5,1 5,5,2 4,1,1 5,1,2
5,5,2 1,5,2 5,1,2 1,1,2
1,5,2 2,5,2 1,1,2 2,1,2
2,5,2 2,5,2 2,1,2 2,1,2
Tabla 6.l. Tabla de estados de análisis de solución 1 Memory.
En este caso el estado constará de tres números, el primer número indica el número
de instrucción del proceso 1, el segundo número el número de instrucción del proceso 2
y el tercer número el valor de la variable processnumber
La gráfica que ilustra la ejecución de este programa es la figura 6.1
Program versiontwo;
var p1 inside, p2inside: boolean;
begin
while true do
begin

Figura 6.1. Gráfica de la ejecución de la versión 1 de Memory Interlock.

while p2inside do;

p1inside: =true;
criticalsectionone;
p1inside:= false;
otherstuffone
end
end;
begin
while true do
begin
while plinside do;
p2inside:=true;
criticalsectiontwo;
p2inside: = false;
otherstufftwo
end
end;
begin
plinside: =false;
p2inside: =false;
parbegin
processone;
processtwo;
parend
end.
program versionthree;
varplwantstoenter p2wantstoenter:boolean;
begin
while true do
begin
p1wantstoenter:=true;
while p2wantstoenter do;
criticalsectionone;
pl wantstoenter: =false;
otherstuffone
end
end;
begin

70 CAP. 6. SINCRONIZACIÓN Y COMUNICACIÓN DE PROCESOS
while true do
begin
p2wantstoenter: =true;
while plwantstoenter do;
criticalsectiontwo;
p2wantstoenter: =false;
otherstufftwo
end
end;
begin
p1wantstoenter:=false;
parbegin
processone;
processtwo;
parend
end.
program versionfour;
var p1wantstoenter,p2wantstoenter:boolean;
begin
while true do
begin
plwantstoenter:=true;
while p2wantstoenter do
begin
pl wantstoenter: =false;
delay(random, fewcycles);
plwantstoenter =true;
end;
criticalsectionone;
plwantstoenter: =false;
otherstuffone
end
end;
begin
while true do
begin
p2wantstoenter: =true;
while plwantstoenter do

begin
delay(random, fewcycles);
end;
criticalsectiontwo;
otherstufftwo
end
end;
begin
parbegin
processone;
processtwo
parend
end.
6.6.6 Solución Final de Memory Interlock (Algoritmo de Dekker)
program dekkersalgorithm
var favoredprocess:(first, second);
plwantstoenterp2wantstoenter:boolean;
begin
while true do
begin
plwantstoenter:=true;
while p2wantstoenter do
if favoredprocess = second then
begin
while favoredprocess second do
p1 wanstoenter: =true;
end;
criticalsectionone;
favoredprocess: =second;
otherstuffone
end
end;
begin

white true do
begin
while plwantstoenter do
if favoredprocess = first then
begin
while favoredprocess =first do
p2wanstoenter: =true;
end;
criticalsectiontwo;
favoredprocess: =first;
otherstufftwo
end
end;
begin
favoredprocess. =first;
parbegin
processone;
processtwo
parend
end.
6.7. Problema de Exclusión Mutua Usando Intercambios(Test and Set)
Esta solución utiliza operaciones de intercambio indivisibles para resolver el

problema, pero sólo se puede implementar en procesadores que tengan alguna de las
operaciones de intercambio indivisibles:
• Registro a Registro (no es factible por costosa)

• Registro a Memoria
• Memoria a Memoria
Program Testandsetexample;
var active: boolean;
var onecannotenter: boolean;
begin
while true do
begin
onecannotenter: =true;

6.8. ALGORITMO DE PETERSON PARA EXCLUSIÓN MUTUA 73
while onecannotenter do testandset(onecannotenter active);

critical sectionone;
active: =false;
otherstuffone
end
end;
var twocannotenter:boolean;
begin
while true do
begin
twocannotenter: =true;
while twocannotenter do testandset(twocannotenter active);
critical sectiontwo;
active:=false;
otherstufftwo
end
end;
begin
active: =false;
parbegin
processone;
processtwo
parend
end.
Este algoritmo tiene como características relevantes:

• Usa Busy Wait
• Es bastante simple.
6.8. Algoritmo de Peterson para exclusión mutua
Recientemente se ha propuesto un algoritmo mucho más simple que el algoritmo de

DEKKER para resolver la exclusión mutua conocido como algoritmo de Peterson que
es dado en seguida.
program peterson
var turn :integer;
enterl,enter2:boolean;
procedure pl;
begin
while true do
begin
enterl:=true;

turn := 2;
while enter2 and turn=2 do;
criticalsectionone;
enterl:=false;
otherstuffone
end
end;
procedure p2;
begin
while true do
begin
enter2: =true;
turn:= 1;
while enterl and turn=l do;
criticatsectiontwo;
enter2:=false;
otherstufftwo;
end
end;
begin
enterl:=false;
enter2: =false;
turn: =l;
parbegin
pl;
p2;
parend
end.
6.9. Semáforos
Es una estructura de datos que se implementa en su forma más simple con un

contador y tiene dos funciones de acceso P y V (espera y señal), permite el manejo de:
• Exclusión mutua.
• Sincronización entre procesos.
La característica más importante de las operaciones P y V es su
INDIVISIBILIDAD, es decir, una vez que se inician no se pueden interrumpir.
Por lo cual se ejecutan con interrupciones deshabilitadas y se les denomina
primitivas.
P(id_sem);
Deshabilita_Interrupciones;
Id_sem.cont:= id.sem cont- 1;
Si (id_sem.cont < 0) Entonces Bloquea_Proceso;

6.9. SEMÁFOROS 75
Habilita_Interrupciones;
Fin P;
V(id_sem);
Deshabilita_Interrupciones;
id_sem.cont =id_sem.cont+1;
Si (id_sem. cont < =0) Entonces Desbloqueo _ proceso;
Habilita_Interrupciones;
Fin V;
Detalles importantes respecto a semáforos:
• El valor inicial del semáforo indica en términos generales el número de unidades
disponibles de algún recurso.
• En el caso de exclusión mutua el número de recursos es 1 y este es el valor inicial
del semáforo.
• Cuando el contador del semáforo tiene valores negativos indica el número de
procesos bloqueados en ese semáforo.
• La exclusión mutua se resuelve en forma sencilla usando semáforos.
• De acuerdo al valor máximo del semáforo se clasifican en:
— Semáforos binarios: valor máximo = 1.
— Semáforos generales: No tiene límite.
6.9.1 Exclusión mutua con semáforos

Programa Exc_Semaforo;
VAR
Sem_mutex: Semáforo Binario;
Proceso1;
___
___
P(sem_mutex);
(* sección crítica *)
V(sem_mutex);
___
___
Fin Proceso1;
Proceso2;
___
___
P(sem_mutex);
(* sección crítica *)
V(sem_mutex);
___
___
Fin Proceso2;

Inicialización;
Sem_mutex: =1;
Parbegin
Proceso 1;
Proceso2;
Parend;
Fin Programa Exc_Semaforo.
Y la comunicación entre procesos?
6.9.2 Problema del productor / consumidor
Se tienen dos procesos, uno produce unidades de información de una en una y las
deposita en un buffer; y el otro las consume del mismo buffer también de una en una.
1. Plantear un solución usando pseudocódigo y considerando:
2. El buffer es de capacidad ilimitada por lo cual no se puede dar la situación de buffer
lleno.
3. El consumidor deberá ser bloqueado si no hay unidades de información.
4. Las operaciones de manipulación del buffer deben hacerse en forma secuencial.
5. Plantee una solución usando:
• — Semáforos generales.
— Semáforos binarios.
Productor consumidor con semáforos generales buffer infinito

PROGRAM PROD_CON_SEM_GEN;
VARIABLES
SEM_UNIDADES:SEMAFORO GENERAL;
SEM_BUFFER:SEMAFORO GENERAL;
PRODUCTOR;
____
PRODUCE_UNIDADES_DE_INFORMAClON;
P(SEM_BUFFER);
AGREGA_UNIDADES_ÁL_BUFFER;
V(SEM_BUFFER);
V(SEM_UNIDADES);
____
FIN PRODUCTOR;
CONSUMIDOR;
____
P(SEM_BUFFER);
P(SEM_UNIDADES);
TOMA_PORCION_DEL_BUFFER;
V(’SEM_BUFFER);
CONSUME_UNIDADES_DE_INFORMACIÓN;

6.9. SEMÁFOROS 77
____
FIN CONSUMIDOR;
INICIALIZAClON:
SEM_UNIDADES:=0;
SEM_BUFFER: =1;
PARBEGIN
PRODUCTOR;
CONSUMIDOR;
PAREND;
FIN PROGRAMA PROD_CON_SEM_GEN.
PROGRAM PROD_CON_SEM_GEN2;
VARIABLES
SEM_UNIDADES: SEMAFORO GENERAL;
SEM_BUFFER: SEMAFORO GENERAL;
PRODUCTOR;
____
PRODUCE_UNIDADES_DE_INFORMAClON;
P(SEM_BUFFER);
AGREGA_UNIDADES_ÁL_BUFFER;
V(SEM_BUFFER);
V(SEM_UNIDADES);
____
FIN PRODUCTOR;
CONSUMIDOR;
____
P(SEM_UNIDADES);
P(SEM_BUFFER);
V(SEM_BUFFER);
CONSUME_UNIDADES_DE_INFORMACION;
____
FIN CONSUMIDOR;
INICIALIZAClON:
SEM_UNIDADES: =0;
SEM_BUFFER:=1;
PARBEGIN
PRODUCTOR;
CONSUMIDOR;
PAREND;
FIN PROGRAMA PROD_CON_SEM_GEN2.
Productor consumidor con semáforos booleanos buffer infinito
PROGRAMA PROD_CON_SEM_BOOL;

CONSTANTES
MAX_BUFFER: =MAX;
TIPO
BUFFER=0. .MAX_BUFFER;
VARIABLES
SEM_CONSUMIDOR : SEMAFORO BINARIO;
SEM_BUFFER: SEMAFORO BINARIO;
NUM_UNIDADES: BUFFER;
PRODUCTOR;
____
PRODUCE_UNIDAD_DE_INFORMAClON;
P(SEM_BUFFER);
AGREGA_UNIDAD_ÁL_BUFFER;
NUM_UNIDADES: =NUM_UNIDADES+ 1;
SI NUM_UNIDADES=1 ENTONCES V(SEM_CONSUMIDOR);
V(SEM_BUFFER);
____
FIN PRODUCTOR;
CONSUMIDOR;
____
(SEM_CONSUMIDOR);
REPITE
P(SEM_BUFFER);
NUM_UNIDADES: =NUM_UNIDADES-1;
V(SEM_BUFFER);
CONSUME UNIDAD_DE_INFORMAClON;
HASTA QUE NUM_UNIDADES=O;
____
FIN CONSUMIDOR;
INICIALIZAClON:
SEM_CONSUMIDOR: =0;
SEM_BUFFER: =1;
NUM_UNIDADES:=0;
PARBEGIN
PRODUCTOR;
CONSUMIDOR;
PAREND;
FIN PROGRAMA PROD_CON_SEM_BOOL.
PROGRAMA PROD_CON_SEM_BOOL2;
CONSTANTES
MAX_BUFFER: =MAX;
TIPO

6.9. SEMÁFOROS 79
BUFFER=0. .MAX_BUFFER;
VARIABLES
SEM_CONSUMIDOR : SEMAFORO BINARIO;
SEM_BUFFER: SEMAFORO BINARIO;
NUM_UNIDADES: BUFFER;
PRODUCTOR;
____
PRODUCE_UNIDAD_DE_INFORMACION;
P(SEM_BUFFER);
AGREGA_UNIDAD_AL_BUFFER;
NUM_UNIDADES: =NUM_UNIDADES+ 1;
SI NUM_UNIDADES= 1 ENTONCES V(SEM_CONSUMIDOR);
V(SEM_BUFFER);
____
FIN PRODUCTOR;
CONSUMIDOR;
VARIABLES
NUM_UNIDADES_ANT_BUFFER;
____
P(SEM_CONSUMIDOR);
REPITE
P(SEM_BUFFER);
NUM_UNIDADES: =NUM_UNIDADES-1;
NUM_UNIDADES_ANT: =NUM_UNIDADES;
V(SEM_BUFFER);
CONSUME_UNIDAD_DE_INFORMACION;
HASTA QUE NUM_UNIDADES_ANT=0;
____
FIN CONSUMIDOR;
INICIALIZAClON:
SEM_CONSUMIDOR: =0;
SEM_BUFFER: = 1;
NUM_UNIDADES: =0;
PARBEGIN
PRODUCTOR;
CONSUMIDOR;
PAREND;
FIN PROGRAMA PROD_CON_SEM_BOOL2.
De lo anterior deducimos lo superfluo de los semáforos generales, es decir, todo lo

que resolvemos con los semáforos generales se puede resolver con los semáforos
booleanos.

Problema productor consumidor semáforos generales buffer finito
PROGRAMA PROD_CONSUMIDOR;
CONSTANTES
max=max_unidades_buffer;
VARIABLES
Sem_productor:SEMAFORO GENERAL;
Sem_consumidor:SEMAFORO GENERAL;
Sem_mutex :SEMAFORO GENERAL;
PRODUCTOR:
____
____
produce_unidades_de_información;
P(sem_productor);
P(sem_mutex);
Agrega_unidad_al_buffer;
V(sem_mutex);
V(sem_consumidor);
____
____
FIN PRODUCTOR;
CONSUMIDOR;
____
____
P(sem_consumidor);
P(sem_mutex);
toma_unidad_del_buffer;
V(sem_mutex),
V(sem_productor);
____
____
FIN CONSUMIDOR;
INICIALIZACION:
Sem_mutex: =I;
Sem_productor: =max;
Sem_consumidor: =0;
PARBEGIN
PRODUCTOR;
CONSUMIDOR;
PAREND;
FIN PROGRAMA PROD_CONSUMIDOR.

6.9. SEMÁFOROS 81
Problema productor consumidor semáforos generales buffer finito
Problema del Productor-Consumidor considerando que se puede dar la condición de

buffer lleno y buffer vacío usando sólo SEMÁFOROS BINARIOS.
PROGRAMA PROD_CONSUMIDOR;
CONSTANTES max=max_unidades_del_buffer;
TIPO Buffer=0.. max;
VARIABLES
Sem_productor :SEMAFORO BINARIO;
Sem_consumidor:SEMAFORO BINARIO;
Sem_buffer :SEMAFORO BINARIO;
unidades :Buffer;
PRODUCTOR;
VARIABLES
espacio:Buffer;
REPITE
Produce_unidad_de_información:
P(sem_buffer);
Deposita_unidad;
unidades: =unidades+ 1;
espacio: =max - unidades;
Si unidades=1 Entonces V(sem_consumidor);
V(sem_buffer);
HASTA espacio=0;
P(sem_productor);
FIN PRODUCTOR;
CONSUMIDOR;
VARIABLES
Que_consumir:Buffer;
P(sem_consumidor);
REPITE
P(sem_buffer);
Toma_unidad_de_información:
unidades: =unidades-1;
Que_consumir:=unidades;
Si unidades=max-1 Entonces V(sem_productor);
V(sem_buffer);
consume_unidad;
HASTA que_consumir=0;
FIN CONSUMIDOR;
INICIALIZAClON:
sem_productor = 0;
sem_consumidor =0;

sem_buffer:= 1;
unidades: =0;
PARBEGIN
PRODUCTOR;
CONSUMIDOR;
PAREND
FIN PROGRAMA PROD_CONSUMIDOR.
6.9.3 Problema de lectores y escritores
Uno de los problemas más comunes en el campo de Bases de Datos es el control de

acceso concurrente a una base de datos por parte de dos tipos de procesos: Lectores y
Escritores.
Un lector es un proceso que no modifica la base de datos por lo cuál, se puede
permitir el acceso concurrente de ellos.
Un escritor es un proceso que actualiza la base de datos, por lo tanto no se debe
permitir el acceso concurrente a la base de datos.
Sólo lectores
Plantear el pseudocódigo de uno de “k” lectores que accesan la base de datos

considerando que se permite el acceso concurrente y tenemos un contador del número
de lectores accesando.
Programa Lectores;
Constantes
Max_1=M;
Tipos
lec= 0,1,2..., max
Variables
Con_lec: Iec;
mutex : Semáforo Binario;
Proceso Lector_i,
___
___
P(mutex):
Cont_lec := cont_lec + 1;
V(mutex);
(* Acceso a la base de datos *)
P(mutex):
Cont_lec : = cont_lec - 1;
V(mutex);
___
___
Fin Proceso Lector_i;

6.9. SEMÁFOROS 83
Inicialización:
Cont_lec : = O;
mutex := 1;
PARBEGIN
___
Proceso Lector_i;
PAREND
FIN Programa Lectores;
Sólo Escritores
Plantear el pseudocódigo de uno de “m” escritores considerando que el acceso es

mutuamente exclusivo.
Programa Escritores;
Variables
mutex: Semáforo Binario;
Proceso Escritor_j;
___
___
P(mutex);
(*Acceso alabase de datos *)
V(mutex);
___
___
Fin Proceso Escritor_j;
Inicialización:
mutex:= 1;
PARBEGIN
___
Proceso Escritor_j;
___
PAREND
FIN Programa Escritores;
Lectores y escritores
Plantear el pseudocódigo que implemente el acceso a una base de datos por parte de
varios procesos de tipo lector y varios procesos de tipo escritor, considerando que:
Los lectores pueden accesar la base de datos en forma concurrente pero mientras
esté accesando un lector ningún escritor podrá realizar su acceso.
Los escritores deben accesar la base de datos en forma mutuamente exclusiva, y
ningún lector podrá accesar la Base de Datos mientras lo esté haciendo un escritor.
Existen dos alternativas de solución:

Solución l. Los lectores deben ser retardados lo mínimo para hacer su

acceso(tienen prioridad los lectores).
Solución 2. Los escritores deben ser retardados lo mínimo para hacer su
acceso(tienen prioridad los escritores).
PROGRAMA Lectores_Prioridad;
Constantes
Max_L = M;
Tipos
Lec = 0,1,2,..., Max_L;
Variables
Mutex: Semáforo Binario;
Esc: Semáforo Binario;
Con_lec: Lec;
Proceso Lector_i;
___
___
P(Mutex);
Cont_Lec := Cont_Lec + 1;
SI Cont_lec = 1 ENTONCES P(esc);
V(Mutex);
(*acceso a la base de datos *)
P(Mutex);
Cont_Lec := Cont_Lec - 1;
SI Cont_lec = 0 ENTONCES V(esc);
V(Mutex);
___
___
FIN Proceso Lector_i;

Proceso Escritor_j;
___
___
P(Esc);
(* acceso a la base de datos *)
V(Esc);
___
___
FIN Proceso Escrito_j;
INICIALIZAClON:
Mutex := 1;
Ese := 1;
Cont_Lec := 0;
PARBEGIN
___

6.9. SEMÁFOROS 85
Proceso Lector_i;
___
Proceso Escritor-j;
___
PAREND
FIN Programa Lectores_Prioridad;
PROGRAMA Escritores_Prioridad;
Constantes
Max_L = M;
Max_E = N;
Tipos
Lee = 0,1,2,..., Max_L;
Ese = 0,1,2,..., Max_E;
Variables
Mutexl : Semáforo Binario;
Mutex2 : Semáforo Binario;
Mutex3: Semáforo Binario;
Lectores: Lec;
Escritores: Esc;
Sem_Lec : Semáforo General;
Sem-Esc: Semáforo General;
Proceso Lector_i;
___
P(Mutex3);
P(Sem_lec);
P(Mutexl);
Lectores: =Lectores+ 1;
SI Lectores = 1 ENTONCES P(Sem_Esc);
V(Mutexl);
V(Sem_Lec);
V(Mutex3);
(* Lectura *)
P(Mutexl);
Lectores : = Lectores - 1;
SI Lectores = 0 ENTONCES V(Sem_Esc);
V(Mutexl);
___
FIN Proceso Lector_i

Proceso Escritor_j;
___
P(Mutex2);
Escritores: =Escritores+l;
SI Escritores = 1 ENTONCES P(Sem_Lec);

V(Mutex2);
P(Sem_Esc)
(* Escritura *)
V(Sem_Esc);
P(Mutexl);
Escritores:=Escritores-1;
SI Escritores = 0 ENTONCES V(Sem_Lec);
V(Mutex_2);
___
FIN Proceso Escritor_j;
INICIALIZACION:
Mutexl := 1;
Mutex2 := 1;
Mutex3 := 1;
Lectores := 0;
Escritores : = 0;
Sem_Lec := 1;
Sem_esc := 1;
PARBEGIN
Proceso Lector_i;
Proceso Escritor_j;
PAREND
FIN Programa Escritores_Prioridad;
Solución general al problema de lectores y escritores
De las soluciones presentadas realmente ninguna es satisfactoria para todos los

casos, puesto que, o se le da la prioridad a los lectores, o se les da a los escritores, pero
no se realiza un BALANCE.
Podría llegar a ocurrir que los lectores estuvieran leyendo información muy vieja, o
podría ocurrir que la información estuviera al día(actualizada) pero nadie la pudiera
leer
Una mejor solución sería aquella en la que se alternarán las prioridades y
proporcionar este balance del que hablamos.
Esto implica definir las reglas en base a las que se van a alternar las prioridades:
1. Un nuevo lector puede hacer su acceso concurrente mientras no esté haciendo su
acceso un escritor Y no este esperando por accesar ningún escritor Esto implica que
mientras esté libre la Base de Datos o estén accesando lectores, los nuevos lectores
podrán accesar siempre y cuando no esté esperando por accesar un escritor
2. Al terminar su acceso el último lector debe dar prioridad al siguiente escritor que
esté esperando (Si existe).
3. Al terminar su acceso un escritor debe dar prioridad a los lectores que ya estén
esperando su acceso(Debe reiniciarse a todos los lectores esperando).
Programa Lectores_Escritores;

6.9. SEMÁFOROS 87
Constantes
Max_L = Máximo_de_Lectores;
Max_E = Máximo_de_Escritores;
Tipos
L=0,1,..., Max_L;
E=0,1,..., Max_E;
Variables
Sem_Lec: Semáforo General;
Sem_Esc: Semáforo General;
Sem_Mutex: Semáforo Binario;
Cont_Lec: L;
Cont_Esc: E;
Escribiendo: Booleano;
Lec_Acce: L;
Proceso Lector_i;
___
P(Sem_Mutex);
SI (Escribiendo) O (Cont_Es <>0)
ENTONCES
Cont_Lec:= Cont_Lec+1;
V(Sem_Mutex);
P(Sem_Lec)
Cont_Lec: = Cont_Lec-1;
FIN ENTONCES
Lec_Acce: = Lec_Acce+1;
SI (Con_Lec <> O) ENTONCES V(Sem_Lec)
SINO V(Sem_Mutex);
(* Lectura *)
P(Sem_Mutex);
Lec_Acce:=Lec_Acce-1;
SI (Lec_Ácce=O ) Y(Cont_Esc <> 0 )
ENTONCES V(Sem_Esc)
SINO V(Sem_Mutex)
___
FIN Proceso Lector_i;

Proceso Escritor_j;
___
P(Sem_Mutex);
SI (Lec_Acce <> 0) Y (Escribiendo)
ENTONCES
Cont_Esc: =Cont_Esc+1;
V(Sem_Mutex);
P(Sem_Esc);

Cont_Esc: = Con_Esc-1;
FIN ENTONCES;
Escribiendo := V;
V(Sem_Mutex);
(* Escritura *)
P(Sem_Mutex);
Escribiendo := F;
SI (Cont_Lec <> 0) ENTONCES V(Sem_Lec)
SINO
SI (Cont_Esc <> 0) ENTONCES V(Sem_Esc)
SINO V(Mutex);
FIN SINO
___
FIN Proceso Escritor_j;
INICIALIZAClON:
Sem_Lec := 0;
Sem_Esc := 0;
Cont_Lec := 0;
Cont_Esc : = 0;
Lec_Acce := 0;
Sem_Mutex := 1;
Escribiendo : =F;
PARBEGIN
Proceso Lector_i;
___
Proceso Escritor_j;
___
PAREND
FIN Programa Lectores_Escritores;
6.9.4 Problema de los filósofos
En un lejano lugar viven 5 filósofos que se pasan la vida filosofando y comiendo.

Comparten un comedor con una mesa circular que misteriosamente siempre está llena
de espagueti; cada filosofo tiene un lugar asignado en la mesa y a la izquierda y
derecha de su lugar está un tenedor.
Debido a que el espagueti está muy enredado es necesario contar con dos tenedores(el
de la izquierda y el de la derecha) para que un filosofo pueda comer.
El problema consiste en plantear un pseudocódigo que evite:
• Deadlock._ Podría ocurrir que simultáneamente los 5 filósofos desearán comer,
tomarán su tenedor derecho (o izquierdo) y nadie podría comer, debido a que se
requieren dos tenedores para comer
• Inanición. Si se estuvieran alternando en comer los filósofos a la derecha e
izquierda de un filosofo “i”, esté podría morir de inanición.

6.9. SEMÁFOROS 89
Programa filósofos;
Constantes
MarFil = 5;
Tipos
Ten = 0,1,2;
Fil = 0,1,..., Max_Fil-1;
Variables
Sem_Áux : Semáforo General;
Num_ten : Arreglo [O..Max_fil-1] DE Ten;
Fil_Bloq : Arreglo [O..Max_fil-1] DE Booleano;
Sem_Mutex: Semáforo Binario;
Sem_Fil : Arreglo [O..Max_fil-1] DE Semáforo General;
I_Fil:Fil;
Procedimiento Filosofo_i;
___
Filosofar;
Toma Tenedor(i);
Comer;
Libera Tenedor(i);
___
FIN Procedimiento Filosofo_i;

Funcion Der(i: Fil):Fil;
SI i = Max_Fil -1
ENTONCES Der:= O
SINO Der: = i+ 1;
FIN Der;
Funcion Izq(i: Fil). Fil;
SI i = 0
ENTONCES Izq : = Max_Fil - 1
SINO Izq := i - 1; FIN Izq;
Procedimiento Tomar_Tenedor(i : Fil);
P(Sem_Mutex);
SI Num_Ten[i] <> 2
ENTONCES
Fil_Bloq[i] := V;
V(Mutex);
P(Sem_Fil[i]);
Fil_Bloq[i] : = F;
Num_Ten[Izq(i)] := Num_Ten[Izq(i)] - 1;
Num_Ten[Der(i)] : = Num_Ten[Der(i)] – 1;
V(Sem_Aux);
FIN ENTONCES;

SINO
Num_Ten[Izq(i)] := Num_Ten[Izq(i)] - 1;
Num_Ten[Der(i)] := Num_Ten[Der(i)] - 1;
V(Sem_Mutex);
FIN SINO
FIN Procedimiento Libera_Tenedor;
Procedimiento Libera_Tenedor(i : Fil);
P(Sem_Mutex);
Num_Ten[Izq(i)]:= Num_Ten[Izq(i)] + 1;
Num_Ten[Der(i)] := Num_Ten[Der(i)] + 1;
SI (Num_Ten[Der(i)] = 2) Y (Fil_Bloq[Der(i)])
ENTONCES
V(Sem_Fil[Der(i)]);
P(Sem_Aux);
FIN ENTONCE;,
SI (Num_ten[Izq(i)] 2) Y (Fil_Bloq[Izq(i)]) ENTONCES
V(Sem_Fil[Izq(i)]);
P(Sem_Áux);
FIN ENTONCES;
V(Sem_Mutex);
FIN Procedimiento Libera_Tenedor;
INICIALIZAClON:
PARA I_Fi1 := 0 HASTA Max_Fil - 1 HAZ
Num_Ten[I_FiI] := 2;
Fil_Bloq[i] : = F;
Sem_Fil[i] = 0;
FIN PARA
Sem_Áux = O;
Sem_Mutex := 1;
PARBEGIN
___
Filosofo 1;
___
PAREND;
FIN Programa filósofos;
6.9.5 Problema de K-procesos en la sección crítica
La siguiente solución intenta resolver el problema de permitir que K de n procesos
puedan ejecutar concurrentemente su sección crítica usando para esto sólo semáforos
binarios.
1. Muestre que es posible que retardo=2 siendo que es un semáforo binario para k = 2
n = 3; k = 2 n 4. Y se podría concluir que no funciona para valores de n mayores.

6.9. SEMÁFOROS 91
2. Plantee una solución que resuelva correctamente dicho problema.

Programa KdeN;
Constantes
K=2;
N=3;
Variables
Contador: Entero;
Retardo : Semáforo Binario;
Procedimiento Proceso_i;
Variables
m :Entero;
___
P(Mutex);
Contador : = Contador-1; Parte 1
m := Contador;
V(Mutex);
Si m <= -1 ENTONCES P(Retardo); Parte 2
(* Sección Crítica *)
P(Mutex);
Contador := Contador+1;
Si Contador <= O Parte 3
ENTONCES V(Retardo);
V(Mutex);
___
FIN Procedimiento Proceso;
INICIALIZAClON
Contador :=K;
Mutex:=1;
Retardo: =0;
PARBEGIN
___
Proceso_i;
___
PAREND,
FIN Programa KdeN;
Solución: considerando el código de los procesos dividido en 3 partes, se puede
verificar que para K=2 y n=3 el semáforo de retardo puede tomar el valor de 2 de
acuerdo a la secuencia ilustrada en la tabla 6.2 secuencia:
NOTAS:
1. X Indica que no es importante.
2. Es fácil deducir que si se cumple para K = 2 y n = 3 también se cumplirá para K = 2
y n =4, K = 2 y n = 5,. . .

CONTADOR M1 M2 M3 RETARDO COMENTARIO

2 X X X 0 Estado inicial
1 1 X X 0 Parte 1 proc 1
0 1 0 X 0 Parte 1 proc 2
-1 1 0 -1 0 Parte 1 proc 3
-1 1 0 -1 0 Parte 2 proc 1
-1 1 0 -1 0 Parte 2 proc 2
0 1 0 -1 1 Parte 3 proc 1
1 1 1 -1 1 Parte 3 proc 2
0 0 1 -1 1 Parte 1 proc 1
-1 0 -1 -1 1 Parte 1 proc 2
-1 0 -1 -1 1 Parte 2 proc 1
0 0 -1 -1 2 Parte 2 proc 1
Tabla 6.2 Una secuencia de ejecución de los procesos en el programa KdeN.
Ejercicio del Problema K de N
Si consideramos que los valores de interés son:

• Contador =2,1,0, -1
• M1, M2, M3 =1, 0, -l
• retardo=-1,0, 1,2
Generar una gráfica que incluya todos los posibles estados y transiciones.
Solución propuesta al problema K de N
Programa k_de_n;
CONSTANTES
k=;
n=;
VARIABLES
Contador : Entero; Mu
Retardo: Semáforo Binario;
Procedimiento Proceso_i;
___
P(Mutex);
Contador := Contador –1;
SI contador <= l
ENTONCES
V(Mutex);
P(Retardo);
V(mutex);
FIN ENTONCES
SINO V(Mutex);
(* Sección Crítica *)
6.9. SEMÁFOROS 93
P(Mutex);
Contador := Contador+1;
SI Contador <= 0
ENTONCES V(Retardo)
SINO V(Mutex);
___
FIN Procedimiento Proceso_i;

INICIALIZAClON:
Contador:=k;
Mutex: = 1;
Retardo:=0;
PARBEGIN
Proceso_i;
___
PAREND
FIN Programa k_de_n;
6.9.6 Problema de los fumadores de cigarros

Existen 3 agentes que a través de 3 ayudantes proporcionan a 3 fumadores 2 de 3
idénticos recursos.
Se dan las siguientes relaciones:
1. El agente 1 proporciona al fumador 1 a través de los ayudantes 2 y 3 la pareja de
recursos necesarios.
2. El ayudante 2 proporciona al fumador 2 a través de los ayudantes 1 y 3 la pareja de
3. El ayudante 3 proporciona al fumador 3 a través de los ayudantes 1 y 2 la pareja de
El objetivo es plantear el pseudocódigo de estos 3 tipos de procesos (Agentes,
Ayudantes y Fumadores), de forma que los Agentes corran viajes veces C/U de ellos.
PARNAS, DL. “on a solution to the cigarette smoker’s problem (without
conditional statements)”
Comm. ACM, 18, 181-183 (1975).
Respecto a esta solución que es dada a continuación resuelva:
1. ¿Cuál es la función de los procesos ayudante.?
2. ¿Cómo terminan los procesos.?
3. ¿Cuál es el objetivo de acum:=0 en fuerza_terminación.?
4. El programa podría terminar, pero comente errores en la parte final de cada
proceso.
5. ¿Cuál es el problema de sem_fumador [i] para i:=1,2 y 4.?
6. Plantee una mejor solución. Programa Cigarro;
Constantes
Viajes =20;

Variables
Sem_Recurso : Arreglo [1..3] DE Semáforo Binario;
Sem_Fumador: Arreglo [1..6] DE Semáforo General;
Sem_Ágentes: Semáforo Binario;
Acum: Entero;
Termina_Ágente: Arreglo [1..3] DE Booleano;
Procedimiento Forza_Terminación;
Variables
i: Entero;
Acum:=0;
PARA i:=1 HASTA 3 HAZ
V(Sem_Recurso [i]);
FIN_PARA;
PARA i:=1 HASTA 6 HAZ
V(Sem_Fumador[i]);
FIN_PARA;
FIN Procedimiento Forza_Terminación;
Procedimiento Agente (Acum, Rec1, Rec2 : Entero);
Variables
I: Entero;
PARA i:=1 HASTA Viajes HAZ
P(Sem_Agentes);
V(Sem_Recurso[Recl]);
V(Sem_Recurso[Rec2]);
FIN PARA;
Termina_Agente[num]: =V;
FIN Procedimiento Agente;
Procedimiento Ayudante (Num, Incremento: Entero);
REPITE
P(Sem_Recurso[Num]);
P(Mutex);
Acum: =Acum+Incremento;
V(Sem_Fumador[Acum]);
V(Mutex);
HASTA Termina_Ágente[1] Y
Termina_Ágente[2] Y
Termina_Ágente[3];
Forza_Terminación;
FIN Procedimiento Ayudante;
Procedimiento Fumador(Num, Valor_Acum : Entero);
REPITE
P(Sem_fumador[Valor_Acum]);

6.9. SEMÁFOROS 95
Acum:=0;
V(Sem_Agentes);
HASTA Termina_Agente[Num];
FIN Procedimiento Fumador;
Inicialización:
PARA Acum:=1 HASTA 3 HAZ
Sem_Recurso[Acum]: =0;
Termina_Ágente[Acum]: =F;
FIN PARA;
Sem_Fumador[Acum]: =0;
FIN PARA;
Acum:=0;
Mutex:=1;
Sem_Agentes:=I;
PARBEGIN
Agente(1,2,3);
Agente(2, 1,3);
Agente(3, 1,2);
Ayudante(1, 1);
Ayudante(2,2);
Ayudante(3,4);
Fumador(I,6);
Fumador(2,5);
Fumador(3,3);
PAREND;
FIN Cigarro;
Solución:
1 Los procesos ayudante proporcionan recursos a los fumadores, de acuerdo a la
siguiente gráfica:
Concluimos que:
i) Independientemente del orden de ejecución los ayudantes 1 y 2 logran hacer

V(sem_fumador[3]); lo cual activa al fumador3.
ii) Independientemente del orden de ejecución los ayudantes 1 y 3 logran hacer
V(sem_fumador[5]); lo cual activa al fumador 2.
iii) Independientemente del orden de ejecución los ayudantes 2 y 3 logran hacer
V(sem_fumador[6]); lo cual activa al fumador 1.
2 y 4 Los agentes terminan después de “viajes” veces. Los ayudantes terminan hasta
que todos los agentes hayan modificado su variable termina _ agente[] haciéndola
verdadera; si por lo menos un ayudante encuentra ésta condición, los ayudantes pueden
terminar, de otra forma no. Los fumadores terminan cuando el agente respectivo haya
modificado a verdadero la variable termina _ agente [], pero si el fumador checa dicha
variable antes de
que se modifique sólo podrá terminar si acaso termina por lo menos un ayudante, pero
de ésta forma ejecutará su código una vez más que su agente respectivo.
3 De no hacerse esto posiblemente algún ayudante pudiera ejecutar
V(sem_fumador[i]) para i > 6
o sea para un semáforo inexistente.
5 Que no tienen ninguna función y se van acumulando operaciones V sobre ellos, y
si el número de viajes fuera grande podría llegar el caso que se sobrepase la
representación de un entero.
6
Programa Cigarro;
Constantes
Viajes20;
Variables
Sem_Recurso : Arreglo[1. .3] DE Semáforo Binario;
Sem_Fumador Arreglo [1..3] DE Semáforo Binario;
Sem_Agentes : Semáforo Binario;
Acum : Entero;
Procedimiento Agente(Num, Red, Rec2: Entero);
Variables
Entero;
P(Sem_Agentes);
V(Sem_Recurso[Recl]);
V(Sem_Recurso[Rec2]);
FIN PARA;
FIN Procedimiento Agente;
Procedimiento Ayudante(Num: Entero);
Variables
i: entero;
P(Sem_Recurso[Num]);
P(Mutex);
pon_bit(Acum,Num);
CASO Acum
6: V(Sem_Fumador[1]);
SINO no_hagas_nada;
FIN CASO;
V(Mutex);
FIN PARA;
FIN Ayudante;

6.10. PIPES 97
Procedimiento Fumador (Num:Entero);

Variables
i: Entero;
P(Sem_Fumador[Num]);
Acum: =0;
V(Sem_Ágentes);
FIN PARA;
FIN Fumador;
Inicialización:
Sem_Recnrso[Acum]:=0;
Sem_Fumador[Acum]: =0;
FIN PARA;
Acum:=0;
Mutex:=1;
Sem_Agentes: =1;
PARBEGIN
Agente(1,2,3);
Agente(2,1,3);
Agente(3, 1,2);
Ayudante(1);
Ayudante(2);
Ayudante(3);
Fumador(1);
Fumador(2);
Fumador(3);
PAREND;
FIN Cigarro;
6.10. Pipes
Unix proporciona un mecanismo de comunicación interprocesos que permite que la

salida de un proceso sea la entrada de otro. A este mecanismo se le conoce como
“pipe”.
Un “pipe” se puede crear con: CREATEPIPE que regresa dos descriptores del
“pipe”, uno para lectura y otro para escritura.
El “pipe” puede ser implementado como un buffer donde se escribe por un extremo
y se lee del otro lado del extremo. Se puede dar el caso deque el buffer esté lleno y se
bloquearía al proceso que escribe, y también si el “pipe” está vacío se bloquearía al
proceso que lee.
El concepto de “pipe” puede ser extendido con:
• EL CONCEPTO DE DIFUSIÓN (BROADCAST) En este caso no se retira

información del “pipe” hasta que haya sido leída por todos los procesos “lectores”.

• EL CONCEPTO DE DELIMITACIÓN. En este caso se puede especificar cuántos

bytes leer del “pipe” o leer el siguiente registro escrito en el “pipe”.
• READBYTES (pipenumber,howmany);
lee los bytes especificados, si no hay, se espera a que haya.
• READRECORD (pipenumber);
lee los bytes escritos en el registro siguiente a ser leído.
6.11. Paso de Mensajes (Mailboxes,Puertos).
Es el enfoque natural para la comunicación entre procesos.

Parámetros a considerar al diseñar este mecanismo:
• Primitivas de bloqueo o no bloqueo.(Envía, Recibe, Reply).

— Bloqueo
— Bloqueo opcional.
• Formato de mensajes (Recepción por tamaño o mensaje).
— Longitud fija o variable.
• Mensajes por copia o por referencia.
• Mensajes de 1-1, l-N, N-1, N-M.
• Hacer mensajes de difusión (Broadcast).
6.12. Regiones críticas

Es un mecanismo de sincronización que protege del acceso concurrente variables.
v.g.
Proceso_i Proceso_j
___ ___
región v do región v do
v:=15; v:=15;
end; end;
___ ___
Fin proceso_i; Fin proceso_j;
Un problema de las regiones críticas es el DEADLOCK ya que las regiones pueden
estar anidadas, pero un compilador podría verificar sise cumple un ordenamiento
JERARQUICO.
6.13. Regiones críticas condicionales
Es similar al concepto de región crítica, pero el acceso a las variables compartidas
es condicionado a una expresión booleana.
Iector_i; escritor_j;
___ ___
región BD do await(escribiendo=F); región BD do await(Iectores=0) y (escribiendo=F);

6.15. EXPRESIONES DE TRAYECTORIA 99
lectores:=lectores+1; escribiendo:= V;
end; end;
(*lectura*) (*escritura *)
región BD do región BD do
lectores: = lectores-1; escribiendo: =F;
end; end;
___ ___
Fin lector_i. Fin escritor_j.
Para la implementación eficiente de este concepto, el proceso que no pueda entrar a

la región crítica debe ser bloqueado y reiniciado cuando la condición por la que espera
sea verdadera.
6.14. Interrupciones virtuales
Pueden servir para realizar sincronización / comunicación entre procesos. El

formato puede ser: Interrupt(processnumber,interruptnumber); que manda la inte-
rrupción indicada al proceso especificado.
Para evitar el uso de interrupciones irrestricto se podría definir su uso sólo para:
1. Mandarse a los hijos o descendientes.

2. Mandarse entre procesos del mismo usuario.
3. Controlare] uso de interrupciones de forma que cada interrupción tenga un
identificador, y el proceso que no tenga dicho identificador no puede hacer uso de
dicha interrupción.
Para definir el “que hacer” cuando ocurra una interrupción, los procesos podrían
hacer un llamado como: Handle(interruptnumber,method) Donde “method” puede
especificar:
1. Ignorar la interrupción.
2. Terminar si la interrupción ocurre.
3. Esperar a que ocurra la interrupción.
4. Si ocurre la interrupción, activar a una rutina de Servicio de Interrupción.
Algunos números de interrupciones virtuales deberían ser reservados para el

sistema operativo v.gr.:
1. Para atender la tecla de ESCAPE.

2. En sistemas operativos con creación jerárquica para señalizar la muerte de un
proceso hijo.
3. División por cero.
4. Temporizadores usados por los procesos.
5. Exceder el número de archivos abiertos permisibles, cantidad máxima de memoria
permitida.
6. Un proceso se detiene esperando reinicio de su padre.
7. Datos disponibles de un dispositivo.

100 CAR 6. SINCRONIZACIÓN Y COMUNICACIÓN DE PROCESOS
6.15. Expresiones de Trayectoria
Consiste en la especificación de qué rutinas deben ser llamadas y en qué orden,

aparte de la definición de las rutinas.
1. path rutinax Especifica que sólo un proceso puede llamar a la “rutinax” a la vez,
pero una vez que termine el llamado, otro proceso (o el mismo) puede llamar a
“rutinax”.|
2. path ruta; ruth; rutc Especifica que antes de ejecutar la rutina “ruth” debe
terminarse la rutina “ruta”, y antes de ejecutar la rutina “rutc” debe terminarse la
rutina “ruth”.
3. path {ruta} Indica que varios procesos pueden ejecutar “ruta” en forma concurrente.
4. path ruta | rutb Especifica que se puede estar ejecutando “ruta” o “rutb” pero no
ambos al mismo tiempo. Ejemplo: path {read} write Lo cual especifica que se
pueden tener varios procesos leyendo concurrentemente, pero la escritura es
exclusiva.
5. Para dar más poder a las expresiones de trayectoria se extiende con la definición de
procedimientos: let procedimiento = secuencia de procedimientos.
Ejemplo:
path TryRead| TtyWrite
path {StartRead|Read}| Write
let TryRead=StartRead
let TryWrite=Write
Iet DoRead= TryRead;Read
tet DoWrite= TryWrite
Dónde los lectores mandan llamar a DoRead y los escritores a DoWrite. La
implementación de Expresiones de Trayectoria no es muy difícil, un compilador
o preprocesador podría convertir las expresiones de trayectoria en su equivalente en
semáforos.
Tienen la ventaja de poder separar la parte “procedural” de un problema y la parte
del control concurrente (sincronización-comunicación).
Un problema es que los procesos son reiniciados dentro del estatuto de “OR-
EXCLUSIVO” en el orden especificado, lo cual no necesariamente es lo que se desea.
6.16. Expresiones Invariantes
En este enfoque se bloquean los procesos que tratan de entrar a algún

procedimiento. El bloqueo es sobre una cola que tiene asociada una expresión
invariante que especifica cuándo debe permitirse la entrada a un proceso.
Si no existe expresión invariante los procesos pueden ejecutar un procedimiento
cuando lo deseen.
La sintáxis es muy limitada y usa contadores INTERCONSTRUIDOS que registran
el número de eventos interesantes para cualquier procedimiento “P”.
Existen 5 contadores:
1. RequestCount(P) Cuenta el número de requerimientos acumulados sobre el procedi-
miento P.

6.16. EXPRESIONES INVARIANTES 101
2. StartCount(P) Cuenta el número de veces que se ha iniciado el procedimiento P, en

forma acumulativa.
3. FinishCount(P) Cuenta el número de veces acumuladas que se ha terminado el
procedimiento P.
4. CurrentCount(P) = Start Count(P) - Finish Count(P)
5. WaitCount(P) = RequestCount(P) - StartCount(P)
Una expresión invariante tiene la forma:

Expresión Comparación Constante
• La expresión puede ser sumas y diferencias de contadores.
• La comparación puede ser <, >, , , =, ó, <>.
v.g. WaitCount(P) - RequestCount(Q) > 4
6.16.1 Ejemplo de Productores Consumidores
PROGRAMA Productores_Consumidores;
EXPORTA GETBUFFER,PUTBUFFER;
CONSTANTES
Size= 10; (* tamaño del buffer *)
TIPOS
Dato = ...; (* tipo de dato del buffer *)
VARIABLES
BUFFER : ARREGLO [O..Size-1] DE Dato;
NextIn,NextOut: 0..Size-1;
(* índice para insertar o borrar siguiente dato *)
INVARIANT PUTBUFFER;
(STARTCOUNT(PUTBUFFER) – FINISHCOUNT(GETBUFFER)) < Size;
(* No sobre producción *)
CURRENTCOUNT(PUTBUFFER) =0;
(* Previene conflictos de productores *)
INVARIANT GETBUFFER,
(STARTCOUNT(GETBUFFER) – FINISHCOUNT(PUTBUFFER)) <O;
(* No sobre consumo *)
CURRENTCOUNT(GETBUFFER) =0;
(* Previene conflictos de consumidores *)
PROCEDIMIENTO PUTBUFFER(QUE:Dato);
BUFFER[NextIn]: = QUE;
Nextln:=(Nextln+ 1) MOD Size;
FIN PUTBUFFER;
PROCEDIMIENTO GETBUFFER( VAR RESULTADO:Dato);
RESULTADO: =BUFFER[NextOut];
NextOut:=(NextOut+1) MOD Size;
FIN GETBUFFER;
FIN PROGRAMA Productores_Consumidores.

Lo anterior demuestra lo sencillo del uso de las expresiones invariantes, ya que se

separa la parte procedural de un problema de la parte que controla la concurrencia y
sincronización de los procesos.
6.16.2 Ejemplo de Lectores y Escritores
Problema de Lectores_Escritores.
INVARIANT Lectura;
(WAITCOUNT(Escritura) + CURRENTCOUNT(Escritura)) =0;
(* si no hay alguien escribiendo o esperando escribir entonces se puede leer *).
INVARIANT Escritura;
(CURRENTCOUNT(Escritura) + CURRENTCOUNT(Lectura)) = 0;
(* Si no hay ningún escritor escribiendo y ningún lector leyendo entonces se puede
escribir *)
NOTA: Al terminar un proceso se asume que el reinicio es de acuerdo al orden de
llegada, pero se debe considerar adicionalmente que cuando termine un escritor deben
reiniciarse todos los lectores esperando.
6.17. Contadores de Eventos
Un contador de eventos es representado como una variable entera no decreciente

inicializada en cero. Lleva el conteo del número de eventos de interés de un programa.
Como un ADT (Abstract Data ‘Lt’pe) los contadores de eventos tienen 3 operaciones:
1. ADVANCE(E) Incrementa en forma atómica el contador de eventos E.
2. READ(E) Regresa el valor del contador de eventos E. Si regresa “n” al menos han
ocurrido “n” operaciones de ADVANCE(E).
3. AWAIT(E reaches v) Bloquea al proceso que llama hasta que se hayan ejecutado “al
menos” y operaciones de ADVANCE(E).
De la anterior definición nos damos cuenta que es posible la ejecución concurrente
de las 3 operaciones.
Daremos un ejemplo de los contadores de eventos usando el problema de
productor-consumidor considerando que se puede depositar y tomar una unidad de
información en diferentes celdas del buffer.
Programa Productor_Consumidor;
CONSTANTES
Size = 10; (* Número de elementos del buffer*)
TIPOS
Dato = ...; (* Tipo del dato en el buffer *)
VARIABLES
In,Out: EventCount;
Buffer: Arreglo [O..Size-1] De Dato;
Procedimiento Productor;

6.17. CONTADORES DE EVENTOS 103
VARIABLES
SequenceNumber:ENTERO;
Valor:Dato;
PARA SequenceNumber:=1 HASTA Infinito
Produce_Valor;
AWAIT(Out reaches SequenceNumber-Size);
Buffer[SequenceNumber MOD Size]: = Valor;
ADVANCE(In);
FIN PARA;
FIN Productor;
Procedimiento Consumidor;
VARIABLES
ValorDato;
PARA SequenceNumber: = 1 HASTA Infinito
AWAIT(In reaches SequenceNumber);
Valor:=Buffer[SequenceNumber MOD Size];
ADVANCE(Out);
Consume_Valor;
FIN PARA;
FIN Consumidor;
INICIALIZAClON:
(* Se inicializan los contadores de eventos *)
PARBEGIN
Productor;
Consumidor;
PAREND:
FIN Productor_Consumidor;
6.17.1 Secuenciadores
Permite asignar un orden arbitrario a eventos desordenados, este orden puede ser
usado para determinar qué proceso obtendrá primeramente un recurso.
Un secuenciador es un ADT implementado con un entero no decreciente
inicializado en cero, su única función de acceso es:
TICKET(S) Regresa el valor actual del secuenciador 5 y después incrementa 5.
Inicialmente 5 es cero. Es una operación atómica y debe garantizarse que no haya dos
llamados a TICKET que regresen el mismo valor.
v.g
Resolvemos el problema anterior de Productor-Consumidor, pero ahora con
múltiples productores y un sólo consumidor:
Programa Productor_Consumidor;
___

104 CAP 6. SINCRONIZACIÓN Y COMUNICACIÓN DE PROCESOS VARIABLES
VARIABLES
___
Turn: Sequencer;
Procedimiento Productor_i;
VARIABLES
Valor:Dato;
LAZO
Produce_Valor;
SequenceNumber: = TICKET(Turn);
AWAIT(In reaches SequenceNumber);
AWAIT(Out reaches SequenceNumber-Size+ 1);
Buffer[SequenceNumber MOD Size]: = Valor;
ADVANCE(In);
FIN LAZO;
FIN Productor_i;
6.18. Monitores
Un monitor es una sección crítica de código generalizada en la cuál un recurso

compartido es manipulado para diferentes procesos de acuerdo a ciertas reglas de
asignación. Este código puede ser pensado como compuesto de dos partes lógicas:
1. El algoritmo de manipulación del recurso. El cuál es un código secuencial y solo
refleja las reglas bajo las cuáles se hace la manipulación del recurso.
2. El algoritmo para determinar el orden en el cuál se asigna el recurso a los procesos.
Esta parte es la que se encarga del control de la concurrencia.
Poniendo como ejemplo el manejo de exclusión mutua usando semáforos, si
separamos del código de los procesos las panes relativas al manejo de los semáforos y
las englobamos en un solo módulo, el módulo resultante es un monitor Dentro de las
ventajas que tiene este enfoque están las siguientes:
1. El código de los procesos se ve y se maneja como si fuera secuencial, pues los
detalles relativos al control concurrente están en el monitor, y los procesos solo
mandan llamar a rutinas del monitor.
2. Al estar englobados en el monitor los detalles de la concurrencia es más fácil
mantener y depurar las aplicaciones. No es necesario depurar dentro de cada
proceso el manejo concurrente, solo se depura en el monitor
El código para el manejo de exclusión mutua usando semáforos se ve así:
VAR
Proceso 1;

6.18. MONITORES 105
—
—
P(sem_mutex);
— (* sección crítica *)
V(sem_mutex);
—
—
Fin Proceso1;
Proceso2;
—
—
P(sem_mutex);
V(sem_mutex);
—
—
Fin Proceso2;
Inicialización;
Sem_mutex:=1;
Parbegin
Proceso1;
Proceso2;
Parend;
Fin Programa Exc_Semáforo;
Usando el concepto de MONITOR el código de los procesos se vería así:
Proceso1;
—
—
Enter;
Exit;
—
Fin Proceso1;
Proceso2;
—
Enter;
Exit;
—
—
Fin Proceso2;
Inicialización;
Parbegin

Proceso1;
Proceso2;
Parend;
Fin Programa Exc_Semaforo.
Mientras el código del MONITOR se vería así:
MONITOR Exclusión;
VAR
Procedimiento Enter;
P(sem_mutex);
Fin Enter;
Procedimiento Exit;
V(sem_mutex);
Fin Exit;
Inicialización:
Sem_mutex:=1;
Fin Monitor Exclusión.
Algo fundamental de un monitor es que es una parte de código es PASIVA, que
solo se ejecuta cuando se manda llamar, y que su parte de inicialización es ejecutada
automáticamente antes de que se mande llamar alguno de sus procedimientos.
Existen cuatro tipos de monitores reportados en la literatura: Monitor Tipo Monitor,
Monitor Tipo Manager, Monitor Tipo Mediador y Monitor Tipo Gladiador
6.18.1. Monitor tipo monitor

Este monitor fue implementado en Pascal Concurrente, lenguaje desarrollado por
Per Brinch Hansen. Es el monitor más simple de todos pues solo tiene tres estados y las
funciones internas son muy sencillas. Una característica distintiva de este monitor es
que el proceso que reinicia a otros debe salir del monitor, es decir abandona el estado
activo. El diagrama de estados de este monitor esta dado en la figura 6.2.
6.18.2. Monitor tipo manager

Este monitor es muy similar al monitor tipo monitor, la diferencia esencial es que
un proceso que es reiniciado debe abandonar el monitor, es decir no se le permite que
entre al estado activo. El diagrama de estados de este monitor se presenta en la figura
6.3.
6.18.3. Monitor tipo mediador

Este monitor fue propuesto por C.A.R. Hoare, tiene la característica de compensar
las desventajas de los monitores tipo monitor y tipo manager. Un proceso que reinicia a
otros puede permanecer dentro del monitor y un proceso reiniciado también puede
permanecer dentro del monitor, El diagrama de estados de este monitor se da en la
figura 6.4.

6.19. REFERENCIAS 107
Figura 6.2. Diagrama de Estados del Monitor Tipo Monitor
Figura 6.3. Diagrama de estados del monitor tipo manager
6.18.4 Monitor tipo gladiador
Este monitor propuesto por Cavers y Brown tiene la característica fundamental de

solo tener un punto de consistencia interno (un punto de consistencia interno ocurre
cuando el proceso que está activo abandona este estado y sigue dentro del monitor). El
diagrama de estados de este monitor se da en la figura 6.5.
6.19.Referencias
Se pueden encontrar en mayor detalle los diversos mecanismos de control de

concurrencias presentados en este capítulo en:
[25], [45], [46], [47], [48], [49], [50], [34], [35], [36], [5l], [52], [18], [15], [39],
[14], [53], [54], [55], [56].

Figura 6.4. Diagrama de estados del monitor tipo mediador.
Figura 6.5. Diagrama de estados del monitor tipo gladiador

Capítulo 7
Manejo de Interbloqueo
(Deadlock)
En este capítulo se revisarán en detalle diversos algoritmos para el manejo de Deadlock.
7.1. Introducción
El problema del DEADLOCK es la situación en la que dos o más procesos están

bloqueados esperando la asignación de recursos que no ocurrirá a menos que se tome una
acción drástica.
Básicamente existen tres enfoques para Atacar el Problema del Deadlock:
1._ Prevención.
En este caso se requiere que cada proceso especifique de antemano la cantidad de
recursos que requerirá, y cuando se desea un recurso se analiza si el nuevo estado es un estado
seguro, de ser así se otorga el recurso, de otro modo NO. De este modo controlando la
asignación de recursos se EVITA EL DEADLOCK.
2._ Detección/recuperación.
En este caso basta que un recurso esté libre para que sea otorgado al momento de
realizar una petición. De este modo es posible que se dé el Deadlock y en forma periódica se
corre un algoritmo que lo detecta. En caso de haber DEADLOCK se corre un algoritmo que
recupera del deadlock a través del reinicio/desasignación de recursos.
3._ Nulo.
Si el deadlock es poco frecuente y además la aplicación no es crítica un enfoque es NO
HACER NADA, en estos casos si ocurre el deadlock y el sistema se para se reinicia el
sistema.
109

110 CAP.7. MANEJO DE INTERBLOQUEO (DEADLOCK)
7.2. Algoritmos de prevención de deadlock
En estos algoritmos, antes de realizar la asignación de recursos se analiza si el nuevo

estado está libre de deadlock. Si el nuevo estado está libre de Deadlock se realiza la asignación
de otro modo el proceso es bloqueado esperando la asignación de los recursos. Además se
requiere que cada proceso especifique de antemano la cantidad de recursos que requerirá en el
peor de los casos, esta es una consideración irreal, puesto que en algunas aplicaciones no se
cuenta con esta información.
Es importante considerar que se permite que se realicen peticiones de un tipo de
recurso a la vez.
7.2.1. Definición de un sistema de asignación de recursos
Un sistema de asignación de recursos esta compuesto por:
1. Un conjunto de procesos. P1P2,..,Pn(n >= 1)

2. Un conjunto de diferentes tipos de recursos: R1R2,..,Rm(m>= 1) Donde para
cada recurso puede haber una o más unidades.
3. Un asignador de recursos.
7.2.2. Representación del estado del sistema
El estado del sistema es definido a través de las estructuras de datos (W, A, f) donde:
MATRIZ W = (w1, w2,.., Wn)
Wi especifica los recursos adicionales que pedirá el proceso i.

W(i, j) especifica el número de unidades del recurso j que pedirá el proceso i.
MATRIZ A = (a1, a2,.., an)
ai especifica los recursos que tiene asignados el proceso i.

A(I,j) especifica el número de unidades del recurso J que tiene asignadas el proceso i
VECTOR f === (f 1, f 2,.., f n)
f i especifica el número de unidades del recurso j que están libres.

7.2.3. Consideraciones básicas
1. Un proceso antes de entrar al sistema de asignación de recursos especifica el
número de unidades de cada tipo de recurso que va a necesitar.
2. La liberación de recursos es voluntaria (NO-PREEMPTIVE).
3. Si un proceso tiene asignados todos los recursos que especificó (w¡<= 0) los
liberará antes de terminar.
4. En el estado inicial el vector de demanda de cada proceso debe ser menor que el
vector de capacidad del sistema (w¡ <= f) ґi.
5. Los procesos solicitan al asignador de recursos solo unidades de un tipo de
recurso, de este modo un proceso solo puede estar esperando por un tipo de
recurso.
7.2. ALGORITMOS DE PREVENCIÓN DE DEADLOCK 111
7.2.4. Definición de estado seguro
x Una secuencia de procesos Pe(l)Pe(2)Pe(3)....Pe(k), donde e(x) es el número de

proceso que termina en el xésimo lugar, es llamada una secuencia de terminación para
el estado (W,A, f) si:
- we(l) > f i-1

- We(i) < = f + 6 ae(j)Jj1=1<I < k
La secuencia es una secuencia de terminación completa si k =- n, es decir, están

contenidos todos los procesos, por lo tanto terminan todos los procesos.
x Un estado del sistema es llamado un ESTADO SEGURO si existe una secuencia de
terminación completa para dicho estado.
7.2.5. Algoritmo de Habermann

El algoritmo de Haberman basa su operación en lo siguiente:
x Si se cumplen las consideraciones expuestas( w¡ < f i), el estado inicial es
seguro y existen para este estado n! secuencias diferentes de terminación.
x Al atender una petición de asignación de recursos se analiza si el estado que se
daría es seguro, de ser así se realiza la asignación de recursos, sino el proceso es
bloqueado esperando la asignación.
x Al momento de que se liberen unidades de algún recurso se deben desbloquear
los procesos para los que se satisfaga su petición de recursos.
7.2.6. Algoritmo de Fontao.

Este algoritmo es similar al de Habermann pero tiene la ventaja que puede correr
en forma concurrente con los procesos que relizan las peticiones de recursos.
El algoritmo de Habermann es un algoritmo secuencial para la prevención de deadlock,
es decir, que no se puede correr concurrentemente el proceso con el asignador de recursos,
esto se puede ilustrar en la figura 7.1.
Para resolver el anterior problema básicamente hay dos alternativas:
a. Concurrencia después de requerimiento avanzado. Lo cual requiere un llamado

extra antes del requerimiento. Esto se ilustra en la figura 7.2
b. Concurrencia sin requerimiento avanzado. Esto se ilustra en la figura 7.3.
De lo anterior podemos concluir que el mejor enfoque es el que no necesita ningún

requerimiento extra. A partir de aquí se hablará del algoritmo de FONTAO que es un
algoritmo de este tipo.

3URFHVRFRQWLQXD
3URFHVR
(VSHUD 3URFHVR(VSHUD
DVLJQDGRU
'HFLGLHQGR 2FLRVR
Figura 7.1 Ejecución secuencial de proceso
5HTXHULPLHQWR 5HTXHULPLHQWR
DYDQ]DGR
3URFHVRFRQWLQXD
3URFHVR (VSHUD
3URFHVR(VSHUD
DVLJQDGRU
'HFLGLHQGR 2FLRVR
Figura 7.2 Concurrencia de proceso y asignador, requiere un requerimiento avanzado.
5HTXHULPLHQWR
Proceso continua
3URFHVR (VSHUD
3URFHVR(VSHUD
DVLJQDGRU
$FWXDOL]D 2FLRVR
Figura 7.3. Concurrencia de proceso y asignador, sin requerimiento avanzado.

El algoritmo concurrente propuesto por FONTAO basa su operación en el cálculo de

una matriz de requerimientos máximos permisibles R.
R=(r1,r2,..,rn)
Donde: ri : Indica el número de unidades de cada recurso que pueden ser asignadas al
proceso i sin llegar a un estado probable de deadlock.
R(i, j) = Especifica el número máximo de unidades del recurso j que se pueden asignar
al proceso i sin llegar a un estado probable de deadlock.
El objetivo central del algoritmo es el cálculo de la matriz R. Para esto además de las
estructuras ya definidas (R, W, A, f), se usan dos conjuntos de procesos:
x HJq El conjunto de procesos que pueden terminar AUN después de quitar q unidades
del recurso j del vector de recursos libres.
j J J j
x T q El conjunto de procesos tales que: PiH q wi<= f + h q dónde: h q = 6j ak
PkHH q
Calculo del conjunto cabeza y conjunto cola:
f=0;
p = Conjunto de todos los procesos;
aux =f ;
aux[j] = aux[j] - q ;
procesos faltantes = n;
fallas = 0;
MIENTRAS (fallas < > procesos_faltantes)
candidato = miembro DEP ();
SI W[ candidato] <= aux ENTONCES
H = H U candidato
P = P – candidato
aux = aux + A[candidato]
procesos_faltantes = procesos_faltantes – 1
fallas = O
FIN ENTONCES
SINO
fallas = fallas + 1
FIN MIENTRAS
T=0;
Aux[J] = aux[j] + q
MIENTRAS (p<>0)
candidato = miembro de P
SI W[candidato] <= aux
ENTONCES
T = T U candidato
P = P – candidato
FIN ENTONCES
FIN MIENTRAS

Teorema de Fontao
Para un estado del sistema representado por {W, A, f) y considerando que dicho estado es
seguro, si un proceso Pi requiere q unidades del recurso j el recurso puede ser otorgado en
forma segura si: Pi ǝ Hjq U Tjq
El calculo de la matriz R como se deduce de lo anterior esta basado en el calculo de los
conjuntos H y T, como podrá suponerse en la matriz R sólo se pondrá el máximo de unidades
que pueden ser otorgadas a cada proceso.
Adicionalmente se puede comentar que:
1. La complejidad del algoritmo es n2

2. Para la construcción de R se usa una matriz S para indicar si se ha calculado ya una
entrada particular dentro de la la matriz R.
3. Además se utiliza un vector surplus que nos indica el número de unidades que pueden
ser quitadas del vector de recursos libres f para cada recurso de forma tal que no
convirtamos el estado actual del sistema en un estado de deadlock.
Comentarios finales del algoritmo
Este algoritmo representa una buena alternativa para la prevención del deadlock en
sistemas multiprocesadores con ciclos de CPU ociosos.
El cálculo de la matriz R puede ser hecho concurrentemente para cada recurso.
El vector surplus es muy útil para poder tomar medidas estadísticas del uso de los
recursos.
PROGRAMA FONTAO;
CONSTANTES
n = max de procesos;
m = max de recursos;
todos = 0,1,2,...,n;
vacio = 0;
max = máximo de unidades de cualquier recurso;
TIPOS
recurso = 0,1,..,max;
vector_recurso = ARREGLO[1..m] de recurso;
conj-proceso = CONJUNTO DE [0,l,..,n]
proceso = 1,2,...,n;
proceso_mas_cero = 0,1,2,. ..,n;
VARIABLES
A : ARREGLO [1..n] DE vector_recurso;
W : ARREGLO [1..n] DE vector_recurso;
F: vector-recurso;
R: ARREGLO [1..n] DE vector_recurso;
H: conj-proceso;
T: conj-proceso;
P : conj-proceso;

S : ARREGLO [1..n, 1..m] DE BOOLEANO;

surplus : vector_recurso;
q : recurso;
aux: vector_recurso;
candidato : proceso;
procesos_faltantes : proceso_mas_cero;
fallas : proceso_mas_cero;
PRINCIPAL
PARA j:=1 HASTA m HACER;
PARA i:=1 HASTA n HACER;
S[i, j]:=FALSO;
R[i, j]:= FALSO;
FIN PARA;
surplus [j] := 0;
Q:= f[J]
aux:=f:
T:= vacio;
H:= vacio;
Procesos_faltantes := n;
MIENTRAS (q > = 0) Y(H < > todos);
aux[j] := aux[j] - q;
P := todos -H;
fallas := 0;
MIENTRAS (fallas < > procesos_faltantes);
candidato := selecciona_candidato_de_P;
SI (W[ candidato] <= aux) ENTONCES
H := H U candidato;
P := P - candidato;
aux := aux + A[candidato];
procesos_faltantes := procesos_faltantes - 1;
fallas := 0;
SI S[candidato,]:= FALSO
ENTONCES
R[candidato, j] := q;
S[candidato, j] := VERDADERO;
FIN ENTONCES
FIN ENTONCES
SINO fallas := fallas + 1;
FIN MIENTRAS;
P := P - T;
aux[j] := aux[j] + q;
MIENTRAS (P<> vacio)
candidato := selecciona_candidato_de_P;

SI W[candidato] <= aux ENTONCES

T := T U candidato;
R[candidato,j] := q;
S[candidato,j] ;= VERDADERO;
FIN ENTONCES
P := P - candidato;
FIN MIENTRAS;
q := q - 1;
FIN MIENTRAS
SI (H = todos) ENTONCES
surplus[j] := q + 1;
SINO estado_actual_inseguro ??????
FIN PARA
FIN FONTAO
7.3. Algoritmos de detección / corrección de deadlock
Los algoritmos de detección de deadlock representan una gran ventaja sobre los
algoritmos de prevención al no requerir que se especifique previamente el número y tipo de
recursos que requerirá cada proceso.
En aplicaciones como las de acceso a una base de datos en las que no se sabe
previamente que archivos ni que registros se van a utilizar, no es posible aplicar algoritmos de
prevención de deadlock, por lo que se aplican algoritmos como los de detección de deadlock y
técnicas de estampillas de tiempo (timestamp).
Los algoritmos de detección tienen que ser diseñados considerando las siguientes
alternativas:
x Cuándo correr.
x Cómo detectar el deadlock.
x Cómo recuperarse del deadlock.
7.3.1. ¿Cuándo correr?
No es enciente que en cada petición al asignador de recursos se corra el algoritmo de

detección, algunas alternativas son:
x Correr el algoritmo cada x peticiones de asignación o liberación de recursos.

x Se puede correr el algoritmo cada y unidades de tiempo.
x Cada x peticiones o cada y unidades de tiempo, según lo que ocurra primero.
Cuál opción es mejor dependerá de:
x Tipo de sistema.
x Utilización de recursos.
x Número de recursos que hay en el sistema.
x Número de Procesos.

7.2. ALGORITMOS DE DETECCIÓN / CORRECIÓN DE DEADLOCK 117
7.3.2. ¿Cómo detectar el deadlock?
Partiendo de la consideración que tenemos n procesos y m tipos de recursos y que para

cada uno de los m tipos de recursos solo existe una unidad, tenemos en cualquier momento
alguno de los siguientes estados:
1. Estado de NO-DEADLOCK. En este caso quedan comprendidos los estados del
sistema en los cuales no existe una cadena circular.
2. Estado de DEADLOCK-PARCIAL. En este caso quedan comprendidos los
estados en los cuales se dan una o más cadenas circulares de espera pero existen
algunos procesos que no participan en ninguna cadena circular.
3. Estado de DEADLOCK-TOTAL. En este caso quedan comprendidos los estados en los
que todos los procesos participan ya sea en una o en más cadenas circulares de espera.
Es importante considerar que el concepto de cadena circular de espera solo tiene

sentido cuando el número de unidades para cada tipo de recurso es UNO, de está forma es
sinónimo decir que se espera por un recurso o se espera por el proceso que tiene asignado
dicho recurso.
Algoritmo de detección para una sola unidad de cada recurso
Considerando este caso simple, un algoritmo de detección / corrección de deadlock
sería simplemente:
1. Marcar todos los procesos como no visitados.

2. Hacer el proceso actual un proceso no visitado y que esté bloqueado, es decir,
esperando por un recurso / proceso. Si ya no hay procesos bloqueados no-visitados NO
EXISTEN MAS DEADLOCKS.
3. Si el proceso actual no está marcado como visitado, marcarlo y hacer el proceso actual
el proceso por el cuál está esperando, si el nuevo proceso actual no está bloqueado, ir
al punto 2; en caso de que si esté bloqueado repetir el punto 3.
Si el proceso actual ya está marcado como visitado se acaba de encontrar un deadlock,

a partir de ahí se recorre la cadena circular marcando los proceso como EN-DEADLOCK, en
este momento se debe corregir el deadlock detectado e ir al punto 1 para detectar cadenas
circulares adicionales que pudiera haber.
Algoritmo de detección para múltiples unidades de cada recurso
El anterior algoritmo es fácil de implementar pero limitado en su aplicación por que en

general se tienen múltiples unidades para cada tipo de recurso, un algoritmo general sería el
siguiente;
Considerando que existen dos tipos de procesos:
x Procesos No-Bloqueados.
x Procesos Bloqueados.
Considerar que los procesos No-Bloqueados Terminan, de forma tal que al liberar los
recursos que tenían asignados algunos de los procesos Bloqueados podrían obtener los
recursos solicitados de forma tal que se convertirían en No-Bloqueados.

Considerar en forma recurrente el punto anterior, es decir, al terminar los

procesos Bloqueados que terminan al terminar los procesos No-Bloqueados, pueden
terminar algunos procesos No-Bloqueados, que al terminar...
Si al final de esta recurrencia el número de procesos bloqueados es cero No Existe
Deadlock, de Otra forma Sí.
En caso de existir Deadlock se debe corregir el mismo(los procesos Bloqueados al final
de la recurrencia son los que están en Deadlock), aunque el proceso de corrección podría
involucrar correr nuevamente el algoritmo de detección.
73.3 ¿Cómo corregir el deadlock?
Esta es una de las partes más difíciles de resolver, puesto que el corregir el deadlock
involucra en general que parte o el total del trabajo realizado por un proceso queda invalidado,
prácticamente el proceso tiene que ser reiniciado o por lo menos regresado a un punto
ESTABLE (CONCEPTO DE TRANSACCIÓN).
Para corregir el deadlock básicamente se deben desasignar unidades de recursos a uno o a
varios procesos, puesto que no siempre ocurre que al desasignar unidades a un proceso quede
corregido el deadlock.
Seleccionar al proceso al que se le desasignarán unidades de algún recurso no es fácil
puesto que debería considerarse:
1. La prioridad del proceso.

2. El tiempo de ejecución acumulada del proceso.
3. El número y tipo de recursos que posee un proceso.
4. Cuál fue el último proceso en bloquearse, lo cuál diría(pero no siempre) que fue el que
causó el deadlock.
7.4. Referencia.
Para ampliar los conocimientos sobre el problema de interbloqueo se recomienda consultas las
siguientes referencias:
[57], [58], [59], [60], [61], [62], [63], [64], [65], [66], [14], [3], [16], [30], [18], [53].

Capítulo 8
Manejo de archivos y discos
8.1. Introducción
En este capítulo presentaremos detalles de manejo de archivos y de la optimización que se

realiza en el manejo de los discos de un sistema computacional.
8.2. Sistema de archivos
Un sistema de archivos debe ser capaz de proporcionar diversas funciones accesibles por el
usuario:
1. Creación, modificación y borrado de archivos. Compartición de archivos entre

diferentes usuarios, controlando los permisos de lectura, escritura y ejecución.
2. Estructuración de los archivos en forma de árbol (estructura de directorios y
subdirectorios).
3. Manejo de archivos por nombres simbólicos y no por características físicas
(localización de almacenamiento, tamaño, dispositivo físico de almacenamiento, etc.).
4. Mecanismos de encriptado y decriptado de datos.
8.3. Organización de archivos
Por ejemplo para llevar el control de los teléfonos de personas podría ser útil un archivo de
datos que constará de los datos de la tabla 8.1.
1RPEUH 7HO«IRQR
9DUJDV5XE«Q
'¯D]5D¼O
5XL]3HGUR
0DUW¯QH]5D¼O
Tabla 8.1. Tabla para llevar una agenda telefónica.
119

120 CAP.8. MANEJO DE ARCHIVOS Y DISCOS
8.3.1. Archivo secuencial
El problema de la tabla 9.1 es que, dado que los datos no están ordenados, buscar un teléfono en
particular puede ser lento. Asumiendo que tenemos N renglones en la tabla, localizar un elemento en
particular tendría los siguientes casos:
x Mejor Caso: Sólo se busca en 1 renglón.
x Peor Caso: Se busca en los N renglones.
x Caso Promedio: Se busca en N+1
2
renglones.
Los casos Mejor y Peor son fáciles de derivar para calcular el caso promedio se ha hecho uso de
N
la fórmula: CasoPromedio = ¦ TodosCasos Y tenemos que: ¦TodosCasos= ¦ i .Para obtener
i=1
Num Casos
simbólicamente el valor de esta sumatoria sumemos dos veces de la siguiente manera:
1 2 3 ... N–1 N
N N -1 N-2 ... 2 1
________ ________ ________ ________ ________
(N + 1) (N + 1) (N + 1) ... (N + 1) (N + 1)
N (N + 1)
N __2___ (N + 1)
de donde N (N + 1) = 2 ¦i concluyendo entonces que: casoPromedio = N
= 2 . Este tipo de
i=1
búsqueda de la conoce como búsqueda secuencial y es a única alternativa de búsqueda cuando los datos
no están ordenados y se cuenta con estructuras auxiliares.
8.3.2. Archivo ordenado usando búsqueda binaría
Si los datos anteriores son ordenados (lo cuál podría hacerse con un algoritmo similar al
QuickSort que tiene un orden de N log N) esto se ilustra en la tabla 8.2. Podemos utilizar una búsqueda
binaria. La ventaja de la búsqueda binaria es que en cada operación el tamaño del problema se reduce a
la mitad.
1RPEUH 7HO«IRQR
'¯D]5D¼O
0DUW¯QH]5D¼O
5XL]3HGUR
9DUJDV5XE«Q
Tabla 8.2. Tabla para llevar una agenda telefónica.
Originalmente el tamaño del problema de búsqueda de un elemento en particular es N, con el

N
N N
primer intento el tamaño del problema se reduce a: 2 con el segundo intento se reduce a:2 = 22 y con el
2
N
iésimo intento se reduce a: 2i de esta manera en el peor de los casos se tendrían que realizar tantos
intentos como el valor de i en la expresiónN2i , despejando de esta fórmula tenemos que: i = [log2(N)].
Como conclusión tenemos entonces:

8.4. ESTRUCUTURA DE UN DISCO 121
x Mejor Caso = 1
x Peor Caso = [logm(N)].
x Caso promedio = 1+[logm(N)]
2
8.3.3. Archivo secuencial indizado
El inconveniente de utilizar una búsqueda binaria es que al hacer altas, bajas y cambios sobre
una tabla ordenada, tenemos que organizar los datos para que se mantengan ordenados, y esto podría
tomar mucho tiempo. Ante este problema una alternativa es la utilización de un índice (similar al de la
parte final de un libro) que contendría el nombre de la persona y un apuntador a dónde esta el elemento
dentro de la tabla. Como puede notarse, los datos en la tabla podrán estar físicamente desordenados,
pero a través del índice se ven lógicamente ordenados. El índice (normalmente) es un archivo aparte
del archivo que contiene los datos, la manera más popular de construir y mantener un índice es a través
del algoritmo de arboles balanceados B-Tree. Los casos para este tipo de búsqueda son:
x Mejor Caso = 1
x Peor Caso = [logm(N)].
x Caso promedio = 1+[log2m(N)]
Dónde m indica el número de vías que tiene el árbol. La gran ventaja de un Índice es que el
algoritmo de mantenimiento es mucho más eficiente que el algoritmo para mantener un archivo
ordenado, y por otro lado es mucho más rápido dado que m es mayor que 2.
8.4. Estructura de un disco duro
Un disco duro consta de:

x Múltiples superficies de lectura y escritura soportados por un eje que gira a una velocidad angular
constante.
x Múltiples cabezas de lectura y escritura soportadas por un brazo que se desplaza
transversalmente.
De esta manera la combinación del movimiento angular de las superficies de lectura/ escritura y el
movimiento transversal de las cabezas de lectura / escritura permite que las cabezas cubran toda la
superficie de lectura / escritura.
Un disco duro contiene uno o más platos (superficies de lectura / escritura). Los platos están
formados de dos materiales, un material duro para darle rigidez (de ahí el nombre de disco duro) y un
medio magnético, donde se guardan los datos. El tamaño del plato define el tamaño físico del disco
duro. La pregunta obligada es: ¿Por qué no agregar más platos a los discos para tener más capacidad?.
La respuesta es que el tamaño del disco duro aumentaría en gran medida, rebasando así el tamaño
estándar para una computadora.
Los platos son organizados para permitir el almacenamiento y la lectura de los datos.
Cada plato se divide en varios miles de pistas, las cuales son pequeños círculos concéntricos.
Cada pista se divide a su vez en sectores. Un sector es normalmente la unidad de
direccionamiento de información más pequeña en un disco duro, y en la mayoría de
los

122 CAP.8. MANEJO DE ARCHIVO Y DISCOS
3ODWR
6HFWRU
%UD]R
&DEH]D
OHFWXUD
HVFULWXUD
%UD]R
&LOLQGUR 5RWDFLµQ

)LJXUD(VWUXFWXUDGHXQGLVFRGXUR
casos puede almacenar 512 bytes de información. Cada pista, normalmente tiene entre 100 y 300
sectores. Esto se ilustra en la figura 8.1
En los sistemas de archivos FAT (File Allocation Table) los sectores se agrupan en bloques más
grandes llamados clusters. el rango de tamaño de los cluster va de 4 sectores (2,048 bytes) a 64 sectores
(32,768 bytes).
8.4.1. Tiempo de acceso a los datos
El tiempo de acceso a datos está definido por el tiempo de búsqueda, el tiempo de movimiento de
la cabeza y el retardo rotacional. El tiempo de búsqueda es el tiempo que le toma a la cabeza
posicionarse sobre el cilindro deseado. Hasta que los datos sean leídos o escritos se tiene que incluir el
tiempo de movimiento de la cabeza para encontrar la pista deseada, además de el tiempo del retardo
rotacional para encontrar el sector deseado.

8.5. TIEMPO DE BÚSQUEDA, TIEMPO DE LATENCIA Y TIEMPO DE TRANSMISIÓN 123
8.5. Tiempo de búsqueda, tiempo de latencia y tiempo de transmisión

El tiempo de búsqueda (tiempo de seek) es el tiempo que tarda el desplazamiento del
brazo (que sostiene las cabezas de lectura / escritura) desde la posición actual hasta el cilindro
donde se leerá / escribirá.
El tiempo de latencia, es el tiempo que tarda en quedar bajo las cabezas de lectura /
escritura el sector donde se leerá / escribirá (esto tiene sentido sólo después de haber
posicionado el brazo en el cilindro correspondiente).
El tiempo de transmisión se refiere al tiempo que se tarda en leer / escribir un bloque de
datos en sectores contiguos. La figura 8.2 ilustra estos tiempos en un disco.
7LHPSR GH
WUDQVPLVLµQ 7LHPSRGH
E¼VTXHGD &DEH]DV
OHFWRUDV
HVFULWRUDV
7LHPSRGHODWHQFLD
)LJXUD7LHPSRGHE¼VTXHGDODWHQFLD\WUDQVIHUHQFLDGHXQGLVFRGXUR

124 CAP.8. MANEJO DE ARCHIVOS Y DISCOS
El mayor de estos tres tiempos es el tiempo de búsqueda, este tiempo es del orden de 10
veces mayor que los tiempos de latencia y transmisión.
Los diferentes algoritmos de planificación del acceso a un disco se enfocan a optimizar el
tiempo de búsqueda de manera prioritaria y en segundo término de optimizar el tiempo de latencia.
8.6. Algoritmos de Planificación de Tiempos de Búsqueda
Algoritmo FCPS (First Come First Served)
En este algoritmo las peticiones de movimiento del brazo del disco son atendidas de acuerdo al
orden de llegada de las peticiones. Cuando existe un número grande de peticiones de desplazamiento
del brazo este algoritmo tiene un pobre desempeño, puesto que se mueve a la siguiente posición (de
acuerdo al orden de llegada) sin considerar la posición actual del brazo.
8.6.1. Algoritmo SSTF(Shortes Seek Time First)
Bajo este algoritmo, la siguiente petición de movimiento del brazo es la que esté localizada más
cerca de la posición actual del brazo. En general este algoritmo tiene un buen desempeño, dado que
minimiza el total de movimiento del brazo maximizando el número de peticiones atendidas. El único
inconveniente es que bajo cargas de trabajo altas, las peticiones que estén localizadas en los extremos
del disco pueden ser postergadas un tiempo grande.
8.6.2 Algoritmo SCAN
Este algoritmo es muy similar al SSTF, pero la siguiente petición a atender, es aquella que
minimice el tiempo de búsqueda en la dirección actual del movimiento del brazo. Cuando ya no existan
peticiones pendientes en la dirección actual del brazo se cambia la dirección de movimiento. El único
inconveniente es que peticiones nuevas en la dirección actual de movimiento del brazo serán atendidas
antes que peticiones anteriores que están en la dirección opuesta de la dirección actual de movimiento.
8.6.3 .Algoritmo N-Step Sean
Las peticiones que son atendidas son las que ya existían al cambiar la dirección de movimiento
del brazo, las nuevas peticiones se atenderán hasta que se atiendan todas las peticiones que estaban al
cambiar la dirección de movimiento del brazo.
8.6.4. Algoritmo C-Scan (Circular Sean)
En este algoritmo se inicia un movimiento hacia adentro en la petición que esté

localizada lo más lejos del eje que sostiene las superficies de lectura / escritura, después

8.8. REFERENCIAS 125
se atiende la petición más cercana en la dirección interna y se continua hasta que no existan peticiones
pendientes hacia adentro. Se reinicia en la petición más externa.
8.7. Optimización Rotacional
Esta optimización trata de minimizar el tiempo de latencia, la estrategia más usada es el

almacenamiento de datos en sectores no contiguos, de manera que puede ser posible leer / escribir un
gran número de sectores en una sola revolución del disco.
8.8. Referencias
Para ampliar los conocimientos sobre el manejo de archivos y discos se recomienda leer las
referencias:
[ 17], [25], [39], [14], [67], [68], [69].

Capitulo 9
Sistemas operativos distribuidos

9.1. Introducción
Gracias al surgimiento de equipo de computo de alta capacidad de procesamiento y bajo

costo, existe una tendencia creciente hacia la realización de procesamiento de datos distribuido,
de manera tal que todos los aspectos de una organización estarán de manera muy natural
dispersos. Las características más relevantes de los sistemas operativos que han soportado esta
dispersión son:
1. Arquitectura de Comunicaciones, Este es el conjunto de programas que soportan que

computadoras diferentes y corriendo sistemas operativos diferentes sean capaces de
comunicarse y soportar: correo electrónico, transferencia de archivos y acceso remoto de
los recursos computacionales.
2. Sistema Operativo de Red. Es una configuración de máquinas de aplicación y uno o más
servidores. Los clientes tienen su propio sistema operativo y un agregado a él (sistema
operativo de red) permita la conexión de los clientes a los servidores. Los servidores
proporcionan facilidades como compartición de dispositivos de almacenamiento e
impresión.
3. Sistema Operativo Distribuido. Es un sistema operativo común, es visto por todos los
usuarios como un sistema operativo centralizado. Se soporta la transparencia de
localización de los recursos computacionales.
Tanto el sistema operativo de red como el sistema operativo distribuido requieren para
su operación de una arquitectura de comunicaciones. La arquitectura de comunicaciones más
ampliamente usada actualmente es el protocolo TCP/IP.
9.2. El protocolo TCP/IP

El protocolo TCP/IP puede estructurarse en cinco capas: aplicación, transporte,
internet, acceso de red y física.
126
127 CAP.9. SISTEMAS OPERATIVOS DISTRIBUIDOS
La capa física se relaciona con la especificación del medio de transmisión, la naturaleza

de las señales, la velocidad de comunicación y aspectos relacionados.
La capa de acceso de red, se refiere al intercambio de datos entre un sistema y la red a la
que se está conectado.
La capa de internet permite la comunicación entre diferente tipos de redes, para esto se utiliza el
Internet Protocol (IP). Para poder realizar la comunicación entre redes diferentes se requiere un
ruteador (router). Las especificación de la fuente y el destino actualmente solo ocupa 32 bits, pero en
un futuro cercano se soportarán direcciones de 128 bits.
La capa de transporte garantiza que las comunicaciones que se realizan sean seguras, para esto
se utiliza comúnmente el Transmission Control Protocol (TCP).
La capa de aplicación da el soporte necesario para las diferentes aplicaciones que se necesitan
correr. Las aplicaciones estándar que corren arriba de TCP son:
x Correo Electrónico (SMTP ó Simple Mail Transfer Protocol), da el soporte para envió y
recepción de correo electrónico.
x Transferencia de Archivos (FTP File Transfer Protocol), permite el intercambio de archivos
entre diferentes computadoras.
x TELNET, permite el acceso remoto de computadoras.
9.3. Computación cliente / servidor
La arquitectura Cliente / Servidor ha reemplazado otras formas de procesamiento distribuido

gracias a su sencillez. El concepto Cliente / Servidor es realmente un concepto de software (no de
hardware) tal que es posible hablar de una aplicación Cliente / Servidor corriendo en una sola
computadora.
El modelo Cliente / Servidor trata de balancear al máximo la cantidad de procesamiento que es
realizado por computadoras poderosas (servidores) y computadoras más modestas (los clientes). El
objetivo de esto es tener un sistema computacional muy eficiente sin una carga excesiva de
comunicaciones y una máxima utilización de los elementos de procesamiento disponibles.
Una de las áreas que más utiliza la arquitectura Cliente / Servidor, es el área de base de datos.
De manera que una gran parte de las aplicaciones de bases de datos en desarrollo actualmente, utilizan
este tipo de arquitectura para lograr un desempeño óptimo (minimización de uso de comunicaciones
con una maximización del uso de los elementos de procesamiento disponibles).
Una de las maneras de realizar la comunicación en una aplicación Cliente / Servidor es a través
de el paso de mensajes distribuido, en este esquema el cliente requiere un servicio ENVIANDO un
mensaje al servidor, el servidor RECIBE el mensaje y proporciona el servicio. Las funciones básicas
son: Envía y Recibe.
Otra manera de realizar funciones en una aplicación cliente / servidor es a través del llamado a
procedimientos remotos (RPC=Remote Procedure Cali), en este caso el cliente manda ejecutar un
procedimiento que está almacenado en el servidor que realiza la función deseada por el cliente.

9.5. 5()(5(1&,$6 128
9.4. Migración de Procesos
La migración de procesos es la transferencia de suficiente información de un programa o

proceso que está corriendo actualmente en la maquina fuente hacia una máquina destino donde el
programa o proceso continuará corriendo. Las razones que motivan la migración de procesos son
diversas:
1. Balanceo de cargas. De manera tal que se utilicen al máximo los elementos de procesamiento
que estén disponibles y el tiempo de terminación de programas sea minimizado. Este balanceo
de cargas debe tomar en cuenta los costos adicionales inherentes al proceso de comunicación
necesario.
2. Mejorar el desempeño del Sistema de Comunicaciones. Si dos procesos se comunican
intensamente y están localizados en computadoras diferentes, esto incrementa la carga por
comunicaciones, si se ubican los dos procesos en la misma computadora es posiblemente
mejorar el desempeño del sistema de comunicaciones.
3. Mejorar la disponibilidad. Si se dará mantenimiento a alguna computadora y está corriendo en
ella un proceso continuo, se podría migrar dicho proceso a otra computadora y garantizar la
continuidad en la ejecución de dicho proceso mientras se da mantenimiento.
4. Uso de Dispositivos Especiales. Un proceso que requiera dispositivos especiales que solo estén
disponible en una computadora de la red, podría migrar hacía dicho nodo y aprovechar
eficientemente dichos dispositivos.
La migración de procesos es una labor muy compleja dado que pueden existir diferentes
sistemas operativos y diferentes plataformas de hardware en un sistema distribuido. Esta situación ha
cambiado drásticamente con el resurgimiento del uso extensivo del concepto de máquina virtual que ha
promovido el lenguaje de programación JAVA. Usando el lenguaje JAVA es posible realizar la
migración de applets de JAVA entre máquinas independientemente de su Hardware y de su sistema
operativo.
9.5. Referencias
Para profundizar sobre el procesamiento de datos distribuido es recomendable consultar las

siguientes referencias:
[39], [70], [14], [71], [72], [73].

APÉNDICE A
Unix
A.1. Introducción a unix
A.1.1. Historia de Unix
Los laboratorios BELL, la compañía General Electric y el proyecto MAC del Instituto Tecnológico de
Massachussets(MIT) se unieron en 1965 para desarrollar un nuevo sistema operativo llamado
MÜLTICS. La idea de este proyecto fue permitir el acceso simultáneo de diferentes usuarios a los
servicios de un sistema computacional- El proyecto dio como resultado una versión preliminar de
MULTICS pero los laboratorios BELL decidieron terminar su participación en el proyecto.
En los laboratorios BELL, Ken Thompson escribió una versión preliminar de un KERNEL para la
computadora GE-645, además Thompson diseñó un juego denominado "Space Travel" para la
Honeyweil 635 cuya ejecución era muy ineficiente, por este motivo decidió emigrar el programa a una
computadora PDP-7. En este momento se unieron Ken Thompson, Dennis Ritchie y Brian Kemighan
escribiendo un sistema de archivos, un manejador de procesos y ciertas utilerías básicas. El nombre de
este sistema fue UNICS jugando un poco con el nombre del sistema anterior MÜLTICS. En 1970 el
nombre fue cambiado a UNIX.
El mismo grupo de desarrollo emigró el sistema operativo de la computadora PDP-7 a una
computadora PDP-11 al mismo tiempo que desarrollaron un ambiente de procesamiento de textos para
el departamento de patentes de los laboratorios BELL. La primera versión del KERNEL de UNIX
ocupó solo 16K.
Ken Thompson al tratar de desarrollar un compilador para el lenguaje FORTRAN termino
desarrollando un lenguaje denominado B basado en otro lenguaje anterior llamado BCPL. El programa
del lenguaje B era lento de forma que Dennis Ritchie se dedico a mejorarlo y surgió el lenguaje C.
129

130 APÉNDICE A. UNIX
En 1973, el sistema operativo UNIX fue reescrito en C. Por cuestiones legales, los laboratorios BELL
no pudieron comercializar el sistema operativo UNIX motivo por el cuál se distribuyo libremente a
universidades y centros interesados.
De esta forma surgieron muchas variantes de UNIX, y fue hasta 1982 cuando los laboratorios BELL
conjuntaron dichas versiones en una sola denominada UNIX System III. AT&T anuncio tiempo
después el lanzamiento de UNIX System V. En la Universidad de California en Berkeley se hicieron
modificaciones y surgió la versión UNIX 4.3 BSD (Berkeley Software Distribution).
Microsoft pidió la licencia a AT&T y produjo XENIX una versión de UNIX para microcomputadoras.
Microsoft hizo equipo con una compañía denominada Santa Cruz Operation (SCO) surgiendo el SCO-
XENIX. En la actualidad hay muchas versiones de UNIX entre ellas la versión para computadoras IBM
se denomina AIX.
A.1.2. Características de diseño de Unix
UNIX se caracteriza por ser:
x “Un ambiente de soporte para el desarrollo de programas”

x “Un sistema operativo diseñado por programadores para programadores”
Las características del diseño fueron:
x Portabilidad entre diferentes plataformas de HardWare.

x Sistema de archivos independiente de los dispositivos.
x Combinar pequeños programas para realizar trabajos complejos.
x Para múltiples usuarios realizando múltiples tareas.
A.1.3. Estructura de Unix
Básicamente la estructura de UNIX se fundamente en que las aplicaciones a través del

SHELL (Interprete de comandos) interactúan con el KERNEL (Compuesto básicamente del
Control de Procesos y del Sistema de archivos) y este a su vez con el Hardware.
A.1.4. Kernel de Unix
El KERNEL está escrito casi completamente en lenguaje C y una pequeña parte esta en código
ensamblador- El KERNEL permite planificar el procesador para múltiples usuarios, además realiza el
manejo del disco y permite comunicamos con los dispositivos de entrada salida.
Los procesos creados por el KERNEL tienen definidos una ENTRADA ESTÁNDAR, una SALIDA
ESTÁNDAR y un ERROR ESTÁNDAR según se ilustra en la figura A.1.
A.1.5. El sistema de archivos
El sistema de archivos de UNIX básicamente maneja tres tipos de archivos:

A. I. INTRODUCCIÓN UNIX 131
Entrada esándar 0 Salida esándar 1

(teclado) (pantalla)
Proceso
Error esándar 2
(pantalla)
Figura A. I. Dispositivos de entrada, salida y error asociados a un proceso.
x Directorios
x Archivos especiales
x Archivos ordinarios
Una característica fundamental de UNIX es que los DISPOSITIVOS son tratados como
ARCHIVOS motivo por el cuál el manejo de DISPOSITIVOS es relativamente fácil.
La estructura de archivos es jerárquica teniéndose directorios que contienen archivos y
directorios donde estos tienen archivos y directorios...
Los directorios que casi siempre están presentes en cualquier sistema UNIX se ilustran en la
figura A.2.
etc bin usr dev u
bin
Figura A.2. Estructura típica de directorios de Unix.
x / Indica el directorio raíz.

x /etc., Contiene comandos de sistema.
x /bin. Contiene comandos administrativos de usuario.

x /usr/bin. Contiene comandos para aplicaciones.

x /dev. Contiene los archivos de definición de dispositivos.
x /u, Contiene directorios para archivos de usuarios.
A.1.6. El Shell
Es un interprete de comandos, pero también tiene su propio lenguaje de programación. Existen

varios SHELLs disponibles donde los más utilizados son;
x C-Shell
x Kom-SheIl
x Boume-Shell
El SHELL tiene la posibilidad de correr procesos en el frente(foreground) o en el

fondo(background). Es muy fácil realizar el redireccionamiento usando los operadores ><>>
La comunicación interprocesos se puede realizar usando:
x Áreas de memoria compartida.

x Semáforos.
x Señales.
x Pipes.
A.1.7. Aplicaciones / Lenguajes de Unix
Unix soporta diversos lenguajes entre ellos:
x C
x Fortran
x Pascal
x Cobol
x Ada
x PL/I
x C++
Para ayudar al desarrollo de aplicaciones usando lenguajes de programación soporta la utilería

make, para automatizar la compilación y ligado de programas.
Soporta adicionalmente depuradores para poder quitar los errores a programas. Para el control
de versiones de archivos maneja una utilería denominada Source Code Control System(SCCS), que
soporta el concepto de archivos increméntales.
A.1.8. Comunicaciones y manejo de redes
x Se soporta el manejo de correo electrónico a través del comando mail.

x Se soporta el copiar archivos entre sistemas UNIX con la utilería uucp(Unix to Unix CoPy).

A. I. INTRODUCCIÓN UNIX 133
x Soporta el protocolo de control de transmisión / protocolo Internet denominado (TCP/IP).

x Soporta el manejo de TOKEN RING.
A.1.9. Editores / Formateadores de texto
Desde sus inicios ÜNIX ha incorporado buenos editores y formateadores de texto.

Entre los editores utilizados están:
x sed
x ed
x ex
x vi
x ined
Entre los formateadores de texto tenemos:
x nroff
x troff
NOTA: Estos dos formateadores utilizan comandos punto para realizar todo el formateo.
A.1.10. Comandos básicos de Unix Entrando y saliendo de Unís
Para entrar a UNIX se debe dar el nombre del usuario a la petición de Login:, después el sistema
preguntará la contraseña del usuario con la petición de Password:
Para salir de UNIX se puede hacer de las siguientes tres formas:

x Presionando: Ctrl-D
x Tecleando: exit
x Tecleando: logout
NOTA: Si se cargó Xwindows es necesario salir como se indico y presionar después

simultáneamente: Ctrl-AIt-BackSpace para regresar al modo texto de UNIX y ahí salir de las formas
indicadas. Otra forma de hacerlo es ejecutar el comando: kill -9 –1
Manipulación de contraseñas
Para modificar la contraseña(password) se hace con el comando: passwd, a lo cuál se pedirá

teclear la anterior contraseña e introducir en dos ocasiones la nueva contraseña. Si se olvida la
contraseña de un usuario es posible como superusuario utilizar el comando:pwdadm para modificar la
contraseña anterior.
Comando ls
Permite ver los archivos de algún directorio, se puede incluir un patrón utilizando los caracteres
comodines * (Cualquier número de caracteres) y ? (Cualquier carácter).
Junto con el comando ls se pueden incluir diversas opciones precediéndolas del signo –.

23&,21 '(6&5,3&,1
D /LVWDWRGRVORVDUFKLYRVLQFOX\HQGRORVHVFRQGLGRV

G /LVWDVRORORVGLUHFWRULRV
O 3URGXFHXQDOLVWDODUJD
U /LVWDDUFKLYRVHQRUGHQLQYHUVRDOIDE«WLFDPHQWH
W /LVWD ORV DUFKLYRV GH DFXHUGR D OD IHFKD GH PRGLILFDFLµQ ORV PRGLILFDGRV ORV PRGLILFDGRV

P£VUHFLHQWHPHQWHSULPHUR

) 0DUFDORVGLUHFWRULRVFRQXQDGLDJRQDOLQYHUWLGD\ORVDUFKLYRVHMHFXWDEOHVFRQXQ

5 /LVWDGLUHFWRULRV\DUFKLYRVUHFXUVLYDPHQWH

7DEOD$,2SFLRQHVGHOFRPDQGR,V
Las opciones de Is se dan en la tabla A.l.

v.gr.
Is -1 /u/pedro
Mostrará un listado conteniendo 7 columnas que indican respectivamente:

x Bits de Permiso del archivo ó directorio.
x Cuenta de ligas.
x Nombre del propietario.
x Nombre del grupo.
x Cuenta de caracteres(tamaño).
x Fecha de última actualización.
x Nombre del archivo o directorio.
Comando cat
El comando cat permite desplegar el contenido de archivos.
x Para ver el contenido de un archivo: cat archivo

x Para imprimir un archivo: cat archivo > /dev/lpl
x Para crear un archivo directamente desde el teclado:
cat > archivo
Ctrl-D
NOTA: Si se desea ver un archivo página a página se puede usar el comando: pg
Comando wc
Permite contar el número de líneas, palabras o caracteres de un archivo. Las opciones son
indicadas en la tabla A.2.
23&,21 '(6&5,3&,1
F Cuenta sólo caracteres.
O Cuenta sólo líneas.
Z Cuenta sólo palabras.

7DEOD$7DEODGH2SFLRQHVGHOFRPDQGRZF
Muestra en el caso de no especificar ninguna opción primero en el número de: Líneas, Palabras
y Caracteres.

$0$1(-2'($5&+,92135
Comando cal
El comando cal permite desplegar un calendario de un mes en particular o de todos los meses de un
año. El formato es:
cal año
cal mes año
Comando who
El comando who permite saber que usuarios están en el sistema y quien es uno (???). Los
formatos son:
who
who am I
Comando man
Permite obtener ayuda del manual en línea de UNIX, el formato comando es: man Ítem
Comando mail
Permite el enviar y recibir mensajes a/de otros usuarios. Para enviar un mensaje a uno o varios usuarios
el formato es:
mail usuario1 usuario2 ...
Ctrl-D Si ya se tiene el mensaje a enviar se puede hacer:

mail usuariol usuario2 ... < archivo-con-mensaje
Para editar los mensajes recibidos el comando es: mail
Los comandos que se pueden usar para editar los mensaje se indican en la tabla A.3.
&20$1'2 '(6&5,3&21
" 'HVSOLHJDODVRSFLRQHVGHOPDLO
Q¼PHUR $YDQ]DHOQ¼PHURGHPHQVDMHVLQGLFDGRV
G %RUUDPHQVDMHV
G %RUUDWRGRVORVPHQVDMHV
KXVXDULRV %XVFDPHQVDMHVGHOXVXDULRLQGLFDGR
0XVXDULR 3HUPLWHSDVDUDOXOWLPRPHQVDMHGHVSOHJDGRDOXVXDULRLQGLFDGR
Q¼PHUR 5HWURFHGHHOQ¼PHURGHPHQVDMHLQGLFDGR
SQ¼PHUR 'HVSOLHJDHOQ¼PHURGHPHQVDMHLQGLFDGR
T 6DOH\GHMDPHQVDMHVHQFROD
UWH[WR&WUO' 3HUPLWHFRQWHVWDUGLUHFWDPHQWHDOWUDQVPLVRUGHOPHQVDMHDFWXDOPHQWHGHVSOHJDGR
6 $JUHJDXQDUFKLYRHOPHQVDMH
7RS 'HVSOLHJDODVSULPHUDVFLQFRO¯QHDVGHXQPHQVDMH
7RSQ¼PHURQXPHUR 'HVSOLHJDODVSULPHUDVFLQFRO¯QHDVGHORVPHQVDMHLQGLFDGRVHQOHUDQJRGDGR
XQ¼PHUR 5HFXSHUDHOPHQVDMHFX\RQ¼PHURVHLQGLFDTXHKDE¯DVLGRERUUDGR
[ 6DOHVLQDFWXDOL]DUFRODGHPHQVDMH
7DEOD$7DEODGH2SFLRQHVGHOFRPDQGRPDLO

136 $31',&($81,;
A.2. Manejo de archivos
A.2.1. Definición de archivo
Un archivo es una colección de datos almacenados en algún dispositivo de almacena miento,

cada archivo esta compuesto de;
x Su nombre.
x Su contenido.
x Información adicional de control e identificación.
A.2.2. Tipos de archivos
Existen tres tipos de archivos en UNIX:
x ORDINARIOS Que son archivos que no tienen un formato interno particular, v.gr. texto ó
código.
x DIRECTORIO Es una tabla de los contenidos de una colección de archivos relacionados,
contiene un nombre y un número de inodo (que es donde está almacenada la información).
x ESPECIALES Representan dispositivos lógicos ó físicos. Se encuentra en el directorio: /dev
A.2.3. Estructura del sistema de archivos y trayectorias
Como ya se comento en el capítulo anterior la estructura del sistema de archivos en UNIX es

jerárquica empezando desde la raíz (/).
El concepto de trayectoria no es más que el camino a través del cuál llegamos a un archivo o
directorio.
Si la trayectoria es descrita partiendo desde la raíz(empieza con una diagonal) se le denomina
trayectoria ABSOLUTA, si se define a partir de la posición actual (no empieza con diagonal) se
denomina trayectoria RELATIVA.
Un punto muy importante es el uso de.. para referirse al directorio padre. Las opciones de
manejo de directorios se ilustran en la tabla A.4.
&RPDQGR 'HVFULSFLµQ
FGWUD\HFWRULD 6HFDPELDODWUD\HFWRULDLQGLFDGD
FG 6HFDPELDDOGLUHFWRULRUD¯]
FG 6HFDPELDDOSDSDGHOQLYHODFWXDO
FG 6HFDPELDDOGLUHFWRULRGHHQWUDGDGHILQLGRFRPRKRPH
PNGLUGLUHF 3HUPLWHFUHDUHOGLUHFWRULRLQGLFDGR
SZG 'HVSOLHJDHOGLUHFWRULRDFWXDO
PYGLUOGLU &DPELDHOQRPEUHGHOGLUHFWRULRGLUODGLU
UPGLUGLUHF %RUUDHOGLUHFWRULRLQGLFDGR
7DEOD$ 7DEODGHFRPDQGRVSDUDPDQHMRGHGLUHFWRULRV

$0$1(-2'($5&+,92137
Permisos de archivos y directorios
UNIX maneja los permisos de acceso a los archivos y directorios clasificando a los usuarios de
la siguiente forma:
x u Se refiere al propietario.
x g Se refiere al grupo.
x Se refiere a los otros(todos los demás).
Además los permisos pueden ser de:
x r De lectura
x w De escritura
x x De ejecución
De este modo surgen 9 bits (el comando Is -1 muestra 10 bits donde el primero indica el tipo de
archivo y los otros 9 indican los permisos a los que nos referimos) que definen los permisos de cada
archivo y directorio respecto a propietario, grupo y todos.
Algunos puntos interesantes son los siguientes:
x Los DIRECTORIOS requieren el permiso de ejecución x para poder accesar los archivos y
directorios que pertenecen a ellos.
x Para que sea efectivo el permiso de escritura w se requiere que DIRECTORIO en cuestión
tenga el permiso de ejecución x.
El comando que permite modificar estos nueve bits de permisos es el comando chmod cuyas
opciones se ilustran en la tabla A.5.
&20$1'2 '(6&5,3&,1
FKPRG>TXLHQ@SHUPLVRDUFK 3HUPLWHDJUHJDUTXLWDUHOSHUPLVRLQGLFDGRVREUHORVDUFKLYRV
FKPRG>TXLHQ@SHUPLVRDUFK UHVSHFWRDORVXVXDULRVLQGLFDGRV

TXLHQSXHGHVHU
J 7RGRVORVXVXDULRVGHOPLVPRJUXSRTXHHOSURSLHWDULR
R 7RGRVORVXVXDULRV
X 3URSLHWDULR

SHUPLVRSXHGHVHU
[ (MHFXWDEOHSDUDGLUHFWRULRVVHUHILHUHDE¼VTXHGD
U OHFWXUD
Z HVFULWXUD

TXL«Q \ ORV SHUPLVRV VH SXHGHQ HVSHFLILFDU XVDQGR XQ
Q¼PHURHQRFWDOFRPRHQHOFRPDQGR
FKPRGDUFKLYR
TXHGDU£DFFHVRLUUHVWULFWRDODUFKLYRO
7DEOD$7DEODGHFRPDQGRFKPRG.

138 $31',&($81,;
$5&+,92 '(6&5,3&,1
DUFKF &µGLJRIXHQWHGH&
DUFKK $UFKLYRLQFOXGHGHHQFDEH]DGRSDUD&
DUFKI &µGLJRIXHQWHGH)2575$1
DUFKS &µGLJRIXHQWHGH3$6&$/
DUFKV &µGLJRIXHQWHGH(16$0%/$'25
DUFKR &µGLJRREMHWR
. 'LUHFWRULRDFWXDO
.. 'LUHFWRULRSDGUH
7DEOD$&RQYHQFLRQHVGH1RPEUHGH$UFKLYRV.
A.2.4. Nombres de archivos
Para especificar los nombres de archivos se tienen definidas convenciones, algunas de las cuales
se ilustran en la tabla A.6.
A.2.5. Comandos para manejos de archivos
En la tabla A.7 se ilustran algunos de los comandos para manejo de archivos.
&20$1'2 '(6&5,3&,1
,V /LVWDDUFKLYRV
FDW 3HUPLWHYHUDUFKLYRVRORVSXHGHFUHDUWDPEL«Q
FS 3HUPLWHFRSLDUDUFKLYRV
PY 3HUPLWHFDPELDUHOQRPEUHDXQDUFKLYR
3J 9HUDUFKLYRVS£JLQDDS£JLQD
PRUH 9HUDUFKLYRVS£JLQDDS£JLQD
UP 3HUPLWHERUUDUDUFKLYRV
WRXFK 6LHODUFKLYRLQGLFDGRQRH[LVWHFUHDXQRGHORQJLWXGFHUR6L\DH[LVWHDFWXDOL]DOD
IHFKDGHOD¼OWLPDDFWXDOL]DFLµQFRQODIHFKDDFWXDO
FVSOLW 6HSDUDUXQDUFKLYRHQEDVHDORVDUJXPHQWRVGDGRV
,Q /LJDGRVQRPEUHVDXQDUFKLYR
6SOLW 6HSDUDXQDUFKLYRHQSHGD]RVGHQO¯QHDV
PYDUFKODUFK 3HUPLWHFDPELDUHOQRPEUHGHODUFKOSRUDUFK
7
7DEOD$&RPDQGRVSDUD0DQHMRGH$UFKLYRV
A.2.6. Comandos para manejo de grupos y propietarios
Los comandos para manejo de grupos y propietarios se ilustran en la tabla A.8.

&20$1'2 '(6&5,3&,1

FKJUSJUXSRDUFKLYR &DPELDHOJUXSRGHODUFKLYRGDGR
FKRZQXVXDULRDUFKLYR &DPELDHOSURSLHWDULRGHODUFKLYRGDGRDOXVXDULRLQGLFDGR
7DEOD$&RPDQGRVSDUD0DQHMRGHJUXSRV\SURSLHWDULRV

$0$1(-2'($5&+,92139
A.3. Procesos
Definición de Proceso
Algunas definiciones de lo que es un proceso:
Un proceso es una tarea que se lleva a cabo dentro del sistema operativo UNIX.
Es un programa que se está ejecutando.
Es la forma de controlar a los múltiples usuarios para compartir los recursos del sistema.
Los procesos son el medio a través del cual un usuario invoca al shell para que este invoque al
kernel y se realice la operación indicada.
A.3.1. Características de un proceso en UNIX

UNIX soporta el concepto de MULTIPROGRAMACION o MULTITAREAS que permite que
varios procesos se ejecuten "simultáneamente".
Además permite que el mismo programa pueda ser ejecutado por diferentes procesos al mismo
tiempo(CODIGO PURO o REENTRANTE).
Un proceso puede ejecutarse en su propio ambiente y comunicarse con otros procesos a través
de llamadas al sistema operativo como podría se el uso de: SEMáFOROS, PIPES, ÁREAS DE
MEMORIA COMPARTIDA, etc.
Los procesos se ejecutan normalmente en MODO USUARIO o MODO PROBLEMA pero
cuando se hace una llamada al sistema se cambia a MODO KERNEL o MODO SUPERVISOR.
El ambiente de un proceso en UNIX se define a través de:
x EL programa siendo ejecutado.

x Los datos utilizados.
x Archivos abiertos.
x Directorio actual.
x Identificador del USUARIO.
x Identificador del PROCESO.
x Identificador del PROCESO PADRE.
x Otras variables de sistema.
A.3.2. Creación de un proceso

La creación de un proceso se lleva a cabo cuando un usuario entra al sistema(LOGIN). En este
momento se define el ambiente del proceso de la siguiente forma:
x Identificador de USUARIO.- El identificador del usuario que entro al sistema,

x Directorio.- El directorio base(HOME) asignado al usuario.
x Programa.- El programa del Shell(sh).
x Identificador del PROCESO.- El número asignado al proceso.
x Proceso Padre.- init.
x Identificador del PADRE.- 1.
x Archivos Abiertos.- La terminal asignada (stdin, stdout y stderr).

140 $31',&($81,;
Cuando el usuario que entro al sistema ejecuta el comando cat MIÓ, se crea otro proceso con
las siguientes características:
x Identíficador de USUARIO- El identificador del usuario que entro al sistema. Esto es heredado.
x Directorio.- El directorio base(HOME) asignado al usuario. Esto es heredado.
x Programa.- El programa cat.
x Identífícador del PROCESO.- El número asignado a este nuevo proceso.
x Proceso Padre,- sh (el del proceso anterior)
x Identificador del PADRE— El asignado al proceso anterior.
x Archivos Abiertos- La terminal asignada (stdin, stdout y stderr) HEREDADA y el archivo
MIÓ.
La creación del proceso que ejecuta el comando cat se realiza a través de la operación llamada
SPAWNING (un pez desovando), esto en forma detallada involucra lo siguiente:
x El ambiente del proceso del shell(sh) es duplicado formando un proceso padre y un proceso hijo
a través de la llamada de sistema fork.
x La llamada de sistema fork regresa el valor del identificador del proceso hijo al proceso padre y
regrese el valor de cero al proceso hijo.
x El padre entra en un estado de espera a través de la llamada de sistema: wait
x El programa cat es cargado en el ambiente heredado del hijo a través de la ejecución del
llamado de sistema: exec
x El hijo solo altera su ambiente abriendo el archivo MIÓ a través de la llamada de sistema: open
x El hijo termina, señalizando al padre a través de la llamada de sistema: exit
x El padre despierta y reinicia ejecución (el shell).
Si el comando ejecutado no es cat MIÓ sino sh el efecto que se tiene es crear otra instancia del
shell(otro proceso) que a su vez podrá crear otra instancia(proceso) al ejecutar otro comando...
Listar Procesos
El comando que permite ver la información de los procesos es: ps. SÍ se desea ver toda la
información se debe usar la opción f: ps -f que muestra para cada proceso la información indicada en la
tabla A.9.
&2/801$ '(6&5,3&,1
8,' (OLGHQWLILFDGRUGHOXVXDULRSURSLHWDULRGHOSURFHVR
3,' (OLGHQWLILFDGRUGHOSURFHVR
33,' (OLGHQWLILFDGRUGHOSURFHVRSDGUH
35, 3ULRULGDGGHOSURFHVR(QWUHP£VDOWRHVHOQ¼PHURPHQRUHVODSULRULGDG
1, 9DORU1LFH8VDGRHQHOF£OFXORGHODSULRULGDG
77< /DHVWDFLµQGHWUDEDMRGHFRQWUROGHOSURFHVR
&0' (OQRPEUHGHOFRPDQGR
UPGLUGLUHF %RUUDHOGLUHFWRULRLQGLFDGR
7
7DEOD$,QIRUPDFLµQGHOFRPDQGRSV

$352&(626141
23&,1 '(6&5,3&,1
H 'HVSOLHJDWRGRVORVSURFHVRVH[FHSWRORVGH.(51(/
I /LVWDGRFRPSOHWR
N 'HVSOLHJDLQIRUPDFLµQGHORVSURFHVRVGH.(51(/
O *HQHUDXQOLVWDGRODUJR
3 SOLVWD'HVSOLHJDLQIRUPDFLµQVµORGHORVQ¼PHURVGHSURFHVRVHVSHFLILFDGRVHQSOLVWD
XOLVWD 'HVSOLHJDLQIRUPDFLµQVµORGHORVSURFHVRVGHORVXVXDULRVHQXOLVWD
7
7DEOD$2SFLRQHVGHOFRPDQGRSV
Las opciones más utilizadas del comando ps son ilustradas en la tabla A. 10.
A.3.3. Procesos de frente y fondo
Unix tiene la capacidad de poder correr un proceso en segundo plano (al fondo) y seguir
trabajando sin tener que esperar a que termine cierto comando.
La forma de realizarlo es por demás simple, solo basta con que se termine el comando con el
carácter ampersand & y listo.
Sino se termina un comando con & estará corriendo en primer plano(frente) y el control se
regresará hasta que termine.
A.3.4. Corres procesos después de salir
SÍ se desea dejar corriendo un proceso después de salir del sistema se debe usar el comando: nohup.
v.gr.:
nohup sort archivo&
x
logout
A.3.5. Controlando la prioridad de los procesos

Una forma de indicarla al sistema operativo que un sistema no tiene alta prioridad es a través
del comando nice cuyo formato es:
nice [-número] comando.
Donde número varía de 1 a 19, entre más grande el valor menor la prioridad.
El superusuario puede correr un proceso con más prioridad usando números negativos
como en:
nice -9 sort.
Se puede alterar la prioridad de un proceso que esté corriendo con el comando:
renice prioridad identificador-proceso.
Donde prioridad va desde -20 a +20 para el superusuario(root) y de +0 a +20 para
un usuario normal.

142 $31',&($81,;
A.3.6. Terminando procesos

Para terminar un proceso el comando adecuado es kill siendo el formato más utilizado:
kill -9 identificador_proceso(s).
Para terminar todos los procesos del usuario y salir del sistema se puede usar la forma:
kill -9 0.
Para terminar los procesos del usuario incluyendo los iniciados en otras terminales usar:
kill-9-1.
Procesos del Sistema.
Cuando/él sistema operativo UNIX arranca se crean ciertos procesos de sistema que nunca
terminan (mientras no se de baja el sistema). El trabajo de estos procesos de sistema conocidos como
DAEMONS es responder a eventos del sistema.
Después de lo anterior se crea el proceso con identificador de proceso 1, que se denomina init.
El proceso init crea tantos procesos que ejecuten getty como terminales estén disponibles. Cuando un
usuario introduce su identificador el proceso getty es reemplazado por un proceso login. Si el usuario
logra entrar al sistema el proceso login es reemplazado por un proceso ejecutando sh (el shell).
Cuando un usuario termina su sesión el proceso sh termina y el proceso init crea un nuevo
proceso getty para la terminal.
A.4. El Shell
A.4.1. Descripición del Shell
Un Shell Permite al usuario interactuar con los recursos de la computadora(Programas,

Archivos y Dispositivos).
El Shell maneja la interacción entre el usuario y el sistema operativo UNIX, realizando la
petición de comandos al usuario, realizando la interpretación de los mismos para el sistema operativo y
el manejo del resultado que da el sistema operativo. De este modo el SHELL recibe el nombre de
INTERPRETE DE COMANDOS.
Dentro del SHELL de UNIX se tiene un lenguaje de programación que permite realizar la
creación de SCRIPTS del SHELL.
El shell no es específico del sistema operativo, motivo por el cuál cada usuario puede tener su
propio SHELL.
A.4.2. Archivos estándar

Automáticamente se abren tres archivos estándar para cada proceso en el sistema:
Entrada Estándar, Salida Estándar y Error Estándar.
La Entrada Estandar(stdin) está asignada por omisión al teclado.
La Salida Estandar(stdout) está asignada por omisión a la pantalla.
El Error Estandart stderr) está asignada por omisión a la pantalla.
Estos valores por omisión pueden ser cambiados utilizando REDIRECCIÓN.

$(/6+(//143
A.4.3. Redirección
La redirección de ]a entrada se lleva a cabo a través del signo de < v.gr. more < arch La redirección de
]a salida se realiza con el signo de > o ^> donde el primero manda la salida al lugar indicado y si existe
el archivo lo borra mientras el segundo lo agrega al final.
v.g.
cat > arch
cat >> arch
La redirección del error estándar se realiza a través del signo de > o ^> pero precediéndolo de un 2
v.g. cat arch 2 > archerror
Sino se desea ver el error, ni guardarlo se puede usar:
cat arch 2 > /dev/null
Existen diversas combinaciones del uso de los operadores de redirección que pueden ser útiles:
comando < archentrada > archsalida 2 > archerror
comando >> archsalida 2 >> archerror < archentrada
comando > archsalida 2 > & 1
Este último ejemplo manda el error al archivo definido como salida previamente. En general se puede
hacer referencia a los archivos de entrada, salida y error ya definidos usando la notación:
&0 Archivo Salida Definido.
&1 Archivo Entrada Definido.
&2 Archivo Error Definido.
A.4.4. Continuación y agrupación de comandos
La continuación de un comando se define terminando el comando con una diagonal invertida \ y

presionado Enter
v.g.
cat arch \
arch2
La agrupación de comandos se lleva a cabo separándolos con un punto y coma ;
v.g.
comando1; comando2
es lo mismo que:
comando1
comando2
A.4.5. Pipes y filtros

Los filtros son comandos que pueden leer su entrada de la entrada estándar y escribir su salida
en la salida estándar, de este modo es posible utilizarlos como un comando intermedio entre
pipes(tubos). Algunos ejemplos de filtros son; sort, wc, cat, cut, grep...

144 $31',&($81,;
v.g.
ls|sort
En algunas ocasiones se desea que la salida de algún comando vaya a dos lugares (en lugar de
un tubo requerimos una T), para esto se utiliza el comando tee
v.g.
Is l tee archl l sort
En este caso la salida del comando Is se manda al archi y al mismo tiempo se manda al comando
sort.El KORN SHELL y el BOURNE SHELL permiten la creación de PIPES con nombre, para realizar
esto se utiliza el comando /etc/mknod dando un nombre y el nombre dado sera el pipe con nombre, v.g.
/etc/mknod BITACORA p
# log < BITACORA
while TRUE
do
read line
echo ‘date +'%H%M%S't #line » /usr/ejemplo/archbita
done < BITACORA
nohup nice log&
A.4.6. Metacaracteres
El carácter ? representa cualquier carácter: v.gr. Is ro? indicará todos los archivos que tengan
como primer letra r, como segunda letra o y como tercer letra cualquier carácter.
El carácter * representa cualquier número de caracteres. Uno de los comandos favoritos a las 2
de la mañana es: rm *
Es posible también especificar una lista de posibles valores v.gr.:
Is [cd]i[lf]
Indica los archivos cuyo nombre empieza con c o d le sigue una i y teminan con 1 ó f
Is [A-Z]r
Indica los archivos cuyo nombre tiene dos letras; la primera es una letra mayúscula y la segunda
la letra r
Is *[ibc]
Indica los archivos cuyo nombre no termina con b o c
A.4.7 Variables del Shell
El carácter $ permite el hacer referencia al valor de una variable del SHELL

(macroexpansión).
Para definir una variable del shell se usa el signo =
v.gr, xy=“hola que tal”
Para referirse al valor de dicha variable se usa $ como en:
echo $xy
Muestra en la pantalla: hola que tal

$(/6+(//145
Para expander una variable del SHELL dentro de un string se encierra el nombre de la variable entre
llaves({ }) y se precede con el signo de $.
v.g.
prefijo = "re"
echo es $prefijotomado el mundo despliega: es el mundo
puesto que la variable prefijotomado no está definida. echo es ${prefijo}tomado el mundo
despliega: es retomado el mundo
Para desplegar las variables del SHELL que están definidas se usa el comando set
Algunas de las variables del shell que normalmente están definidas se indican en la tabla A.
11.
9$5,$%/( '(6&5,3&,1
/2*1$0( (OQRPEUHFRQHOTXHVHKL]RHOORJLQ
+20( (OQRPEUHGHOGLUHFWRULRFRQHOTXHVHGLRORJLQ
3$7+ 8QDOLVWDRUGHQDGDGHQRPEUHVGHWUD\HFWRULDGHGLUHFWRULRVVHSDUDGRVSRU(OVKHOO
EXVFDHQHORUGHQHVSHFLILFDGRGHQWURGHO3$7+ORVFRPDQGRVTXHVHGHVHDQ
HMHFXWDU
36, (OSURPSWSULPDULRGHVLVWHPD
36 (OSURPSWVHFXQGDULRGHOVLVWHPD
,)6 (OSURPSWVHFXQGDULRGHOVLVWHPD
7DEOD$$OJXQDVYDULDEOHVGHO6KHOO

A.4.8. Exportando variables
Las variables que se definen solo son validas dentro del proceso que realiza la definición, si se desea
que dichas variables sean visibles dentro de los procesos hijos(nietos, biznietos,...) es necesario usar el
comando export nombre-variable.
Para verificar las variables que han sido exportadas se usa el comando export sin parámetros.
Es importante destacar que las variables de un proceso hijo nunca serán vistas desde el proceso padre.
Para desplegar las variables definidas a nivel local se usa el comando set.
Para desplegar las variables que han sido heredadas se usa el comando env.
A.4.9. Variables como comandos
Para almacenar en una variable un comando para ser ejecutado posteriormente es necesario delimitar el
comando entre comillas invertidas (no confundir con las comillas sencillas), v.gr.;
ahora='date'
echo $ahora
Desplegará la fecha actual

146 $31',&($81,;
A.4.10. Caracteres de escape del Shell
La diagonal invertida permite que no se interprete el carácter enseguida.

v.gr.:
echo\$8
Despliega: $8 Las comillas simples permiten que el shell no interprete nada:
v.gr.:
echo ‘hola $1’
Despliega: hola $1
Las dobles comillas le indican al shell que interprete todos los caracteres especiales.
v.gr.:
dir="Directorio actual es “pwd”
echo $dir
Desplegará el mensaje: Directorio actual es
seguido del directorio actual
A.4.11. Tipos de Shell
Con AIX vienen incluidos los siguientes SHELUs:

x Boume
x C
x Kome
x Restricted
x Trusted
Bourne Shell
Es un shell ampliamente usado desarrollado en 1975 por S.R. Boume en los laboratorios BELL,
el nombre viene del apellido de su desarrollador. La forma de localizarlo es en:/bin/bsh se invoca con
bsh y su indicador (prompt) es $.
Soporta el manejo de excepciones a través del comando trap, soporta el concepto de
pipes con nombre (named pipes), soporta variables locales y globales (se exportan con el
comando (export), soporta las estructuras de control if-then-else, case, for, while y until a
diferencia de C SHELL y KORN SHELL usa las utilerías test y expr para realizar la
evaluación de expresiones condicionales.
C Shell
Es un shell desarrollado en la universidad de Berkeley por Bill Joy y un grupo de

alumnos que acepta comandos similares en sintaxis a la sintaxis del lenguaje C. Está localizado
en:/bin/csh se invoca con csh y su indicador(prompt) es %
Soporta el manejo de la historia de comandos a través de history, soporta el crear alias de los
comandos, el control de las variables se realiza a través de los comandos set y setenv,

$(/6+(//147

los operadores condicionales son los del lenguaje C, ofrece las construcciones if-then-else,
switch, foreach, repeat y while.
Korn Shell
Este shell fue desarrollado por David Kom en AT&T, es resultado de tomar características de los dos
anteriores y agregar algunas nuevas. Este shell es el que se usa en AIX por omisión. Se localiza en:
/bin/ksh se invoca con: ksh y el indicador (prompt) es $
Incorpora lo mejor del C SHELL y del BOURNE SHELL, es un poco más rápido que el C SHELL
pero más lento que el BOURNE SHELL, adicionalmente a las construcciones del C SHELL soporta el
select similar al case para elegir las opciones de un menú.
Una de las características más importantes del ksh es el poder definir alias para los comandos usando el
comando alias.
v.g.
alias dir=“ls –1”
De este modo al dar dir se ejecutará el comando Is –1
Otra característica propia del ksh es el poder exportar todas las definiciones de variables y de alias
utilizando la variable ENV. Suponiendo que las definiciones de las variables y aliases están definidas
en el archivo varal del directorio del usuario basta con hacer lo siguiente:
ENV=$HOME/viral
export ENV
Dentro del ksh se pueden editar los comandos anteriores haciendo lo siguiente:
set -o vi
Después para editar los comandos anteriores se debe hacer con la secuencia siguiente:
ESC Entra en modo edición.
k Comando Previo
j Comando Siguiente
Shell Restricted (Restringido)
Este shell es idéntico al shell Boume escepto que no se pueden realizar algunos comandos como:
cambiarse de directorio (cd)
utilizar redirección (<, >, >>)
especificar los nombres de comandos empezando con diagonal (/)
definir el valor de la trayectoria de búsqueda de comandos a través de la variable (PATH)
Este shell se localiza en el directorio /bin/Rsh, para invocarlo se hace con: Rsh y el indicador (prompt)
es $
Shell Trusted (Privilegiado)
Este shell proporciona un ambiente privilegiado desde el cuál se pueden realizar operaciones
administrativas del sistema. Permite la ejecución de comandos catalogados como privilegiados
(trusted).

148 $31',&($81,;
Este shell se localiza en /bin/tsh la forma de invocarlo es con Ctrl-X Ctrl-R, el indicador
(prompt) es tsh >
Para entraba este shell se debe estar como superusuario(su) o como raíz(root).
A.4.12. Terminales virtuales
El concepto de terminales virtuales proporcionan una forma de múltiples procesos interactivos

ACTIVOS SIMULTÁNEAMENTE.
Para iniciar una terminal virtual se hace a través de: open sh
Para moverse entre las terminales virtuales se hace a través de: Alt-Action( si guíente terminal virtual)
o Shift-Action (anterior terminal virtual).
Para distinguir las múltiples terminales terminales virtuales es posible cambiar el tipo de letra(font) y
color de cada una de ellas usando los comandos:
chfont -1#
chcolor -b# -f#
Para desplegar los colores y tipos de letra disponibles se usan los comandos:
Iscolor
Isfont
NOTA: Los valores por omisión de Xwindows están en el directorio raíz en un archivo denominado
Xdefaults
A.4.13. Comandos de selección

Los comandos de selección son ilustrados en la tabla A.12.
&20$1'2 '(6&5,3&,1
DZN /HQJXDMHGHE¼VTXHGD\SURFHVDPLHQWRGHVWULQJV
FXW 3HUPLWHVHOHFFLRQDUFROXPQDVGHXQDUFKLYR
GLII &RPSDUDGRVDUFKLYRV\VHOHFFLRQDODVGLIHUHQFLDV
JUHS 6HOHFFLRQDORVUHQJORQHVTXHFXPSOHQHOFULWHULRGDGRVµORXQFULWHULR
(JUHSH[WHQGHGJUHS 6HOHFFLRQDLRVUHQJORQHVTXHFXPSOHQORVP¼OWLSOHVFULWHULRVGDGRV
)JUHSIDVWJUHS 6HOHFFLRQDORVUHQJORQHVTXHFXPSOHQORVP¼OWLSOHVFULWHULRVGDGRV
KHDG 6HOHFFLRQDORVSULPHURVUHQJORQHVGHORVDUFKLYRV
OLQH 6HOHFFLRQDHOSULPHUUHQJOµQGHORVDUFKLYRV
VHG 3HUPLWHHGLWDUORVIOXMRVGHGDWRV
WDLO 3HUPLWHVHOHFFLRQDUODV¼OWLPDVO¯QHDVGHORVDUFKLYRV
XQLT 6HOHFFLRQDUHQJORQHVHOLPLQDQGRUHSHWLFLµQ6µORVLVREUHORTXHVHRSHUDHVW£RUGHQDGR
ZF &XHQWDFDUDFWHUHVSDODEUDV\O¯QHDVGHXQDUFKLYR
7DEOD$&RPDQGRVGHVHOHFFLµQ.
Muestra la primer línea del archivo:

line < archivo
Muestra las 10 primeras líneas del archivo:
head archivo que es lo mismo que sed -e ‘1 1,$d’ archivo

$(',725(6149

Muestra las últimas 10 líneas del archivo:
tail archivo
Mostrar los archivos en los que aparece la palabra CAPITULO:
grep CAPITULO * Todas las ocurrencias.
grep -1 CAPITULO * Solo los nombres de los archivos.
grep -n CAPITULO * Mostrar números de línea.
Mostrar cuantos archivos tienen la palabra CAPITULO:
grep -1 CAPITULO * wc –1
Si se tiene un archivo datos donde los campos están separados por : y se desea extraer el
campo 2 y el campo 5 del archivo, siempre y cuando el renglón tenga la palabra LIBRO:
grep LIBRO datos|cut -f2,5 -d:
Obtener los caracteres del 1 al 20 y del 55 en adelante del listado de un directorio:
ls-l[cut-cl-20,55-
A.5 Editores
A.5.1. Editores de UNIX
Dentro del ambiente unix se tienen disponibles diversos editores y herramientas para
manipulación de strings según se indica en la tabla D.6.
(',725 '(6&5,3&,1
Ed (VXQHGLWRUGHO¯QHDTXHVµOR SHUPLWHWUDEDMDUFRQXQDUFKLYRDXQWLHPSR
Red 9HUVLµQUHVWULQJLGDGHOHGLWRUHGSDUDXVDUVHFRQHO6+(//5(67,&7('
([ (GLWRUGHO¯QHDVLPLODUDOHGSHURSXHGHHGLWDUP¼OWLSOHVDUFKLYRVDXQWLHPSR
(GLO 9HUVLµQSDUDSULQFLSLDQWHVGHH[
Vi (GLWRUGHSDQWDOODFRPSOHWDVHSXHGHQHMHFXWDUODPD\RU¯DGHORVFRPDQGRVGHH[
9LHZ 9HUVLµQSDUDVµOROHFWXUDGHOYL
9HGLW 9HUVLµQSDUDSULQFLSLDQWHVGHOYL
7YL 9HUVLµQSULYLOHJLDGDGHOYLSDUDXVRVGHDGPLQLVWUDFLµQGHOVLVWHPD
JUHSHJUHSIJUHS +HUUDPLHQWDVSDUDE¼VTXHGDGHSDWURQHVGHQWURGHORVDUFKLYRVHJUHS\IJUHSVRQ
GRVYDULDQWHVGHOJUHSTXHVRQXQSRFRP£VHILFLHQWHV
6HG (GLWRUGHIOX-RV6WUHDPVSDUDDUFKLYRV
DZN (GLWRUGHIOXMRV6WUHDPVSDUDDUFKLYRV
7DEOD$(GLWRUHVHQ81,;.
Grep
El comando grep (Globally look for a Regular Expression and Print) permite encontrar cada
ocurrencia de una palabra o frase en algún archivo de UNIX.Las opciones de este comando se ilustran
en la tabla A. 14.
Sed
El comando sed (Stream EDitor) permite realizar edición de archivos, v.g. sed archivo.
150 $31',&($81,;
23&,1 '(6&5,3&,1
F 0XHVWUDODFXHQWDGHODVO¯QHDVHQODVTXHKXERDSDUHDPLHQWR
L ,JQRUDPD\¼VFXODVPLQ¼VFXODVGXUDQWHODFRPSDUDFLµQ
O 0XHVWUDVµORORVQRPEUHVGHDUFKLYRVHQORVTXHKD\DSDUHDPLHQWR
Q 3UHFHGHFDGDO¯QHDHQODTXHKD\DSDUHDPLHQRFRQHQ¼PHURGHO¯QHDGHODUFKLYR
V 6XSULPHPHQVDMHVGHHUURU

9 'HVSOLHJDODVO¯QHDVHQODVTXHQRKD\DSDUHDPLHQWR
; 'HVSOLHJDVµORDSDUHDPLHQWRVH[DFWRVVµORFRQIJUHS
\ ,JQRUDPD\¼VFXODVPLQ¼VFXODV

7DEOD$2SFLRQHVGHOFRPDQGRJUHS
A.5.2. El Editor vi
Es un editor de pantalla completa, de muy amplio uso en las instalaciones UNIX. Permite
la creación y modificación de archivos texto, no tiene capacidades de formateo. Trabaja
siempre sobre una copia del archivo en un buffer de edición. Tiene básicamente dos modos de
operación:
x Modo Comando.- En el cuál todos los teclazos son interpretados como comandos. Este es el
modo con el que se entra al vi.
x Modo Edición.- En este modo todos los comandos se interpretan como texto. Para regresar al
modo comando se presiona ESC.
Tiene como característica sobresaliente el poder realizar búsqueda y reemplazo de texto pudiendo
utilizar la característica de apareamiento de patrones.
Movimiento en el Documento
Algunas teclas que se pueden usar en el modo comando para moverse en el archivo se indican
en la tabla A.15.
TECLAS MOVIMIENTO
TECLAS 029,0,(172
Kµ)OHFKDL]TXLHUGD 8QFDU£FWHUDODL]TXLHUGD
Mµ)OHFKD$EDMR 8QDO¯QHDKDGDDEDMR
Mµ)OHFKD$EDMR 8QDO¯QHDKDGDDUULED
µ)OHFKD'HUHFKD 8QFDU£FWHUDODGHUHFKD
&WUO)µ$Y3£J 8QDSDQWDOODKDGDDGHODQWH
&WUO%µ5H3£J 8QDSDQWDOODKDFLDDWU£V
&WUO' 0HGLDSDQWDOODKDFLDDEDMR
&WUO8 0HGLDSDQWDOODKDGDDUULED
6HPXHYHDODO¯QHD
6HPXHYHDOI¯QDOGHODUFKLYR
6HPXHYHDOILQDOGHOUHQJOµQ
Z 6HPXHYHXQDSDODEUDKDFLDDGHODQWH

7DEOD$&RPDQGRVGHPRYLPLHQWRHQYL

$+(55$0,(17$6'(0$1(-26'('$726 151

Edición básica en vi
Para entrar a editar un archivo se hace con: vi arch

Para agregar texto estando en modo comando se presiona: a después de lo cuál se debe teclear
el texto del archivo.
Para insertar texto se debe presionar i después teclear e! texto a insertar.
Para abrir una nueva línea después de la posición del cursor se presiona o para abrirla antes del
cursor se presiona O
Para borrar una línea se presiona dd.
Para borrar hasta el fin de línea se presiona d$ ó D
Para borrar una palabra se presiona dw
Para borrar un carácter se presiona x.
Para reemplazar un carácter se presiona r seguido del nuevo carácter.
Para entrar a modo reemplazo se presiona R
Para regresar al modo comando se debe presionar: ESC
Para salir grabando estando en modo comando se debe presionar :wq ó presionando ZZ
Para salir sin actualizar estando en modo comando, se presiona :q!
Búsqueda y Reemplazo
La característica de búsqueda y reemplazo de vi permite realizar la edición de documentos de

una forma más fácil.
Estando en el modo comando y desear buscar una cadena se presiona: /textobuscado/ lo
cuál localizará la siguiente ocurrencia hacia adelante de textobuscado. Para buscar otras
ocurrencias se puede usar n para buscar en la misma dirección de la búsqueda anterior ó N
para buscar en la dirección contraria a la búsqueda anterior. Si se desea buscar hacia atrás se
usa: Ptextobuscado?
Para realizar el reemplazo se hace de la forma siguiente:
:g/textobuscado/s//nuevotexto/g
Deshacer, repetir comandos
Para deshacer la operación anterior basta con presionar; u Para repetir el último comando
realizado se presiona:
Personalización del vi
Para ver la definición actual de las variables del editor se ejecuta: :set all
Para personalizar los valores por omisión se debe crear un archivo $HOME/.exrc que contenga
los comandos de definición del vi v.g.:
set directory=/u/juan/tmp
Permite definir el directorio donde se almacena el buffer de edición temporal. Si el
sistema se cae y se desea recuperar el archivo que se estaba editando se debe hacer: vi -r
archivo

152 $31',&($81,;
A.6. Herramientas de manejo de datos
A.6.1 El Comando find

Este comando permite en forma recursiva realizar operaciones sobre archivos que
cumplan cierto criterio especificado, la forma general del comando es:
find dedonde busca acción
v.g. find . -name “m*” -exec Is -1 { }\;
Para los archivos cuyo nombre empieza con m ejecuta el comando Is –1
find . -name hola -print
Para los archivos cuyo nombre es hola los muestra en la pantalla.
find . -name m \* -ok Is -1 { }\;
Para los archivos cuyo nombre empieza con m aplica en forma selectiva(pregunta y/n) el
comando Is –1
Algunas de las opciones del comando find son ilustradas en la tabla A. 16.
23&,1 '(6&5,3&,1
W\SHI 6HDSOLFDDDUFKLYRVRUGLQDULRV
W\SHG 6HDSOLFDDGLUHFWRULRV
VL]HQ 6µORORVDUFKLYRVP£VJUDQGHVTXHQEORTXHV
VL]HQ 6µORORVDUFKLYRVPHQRUHVTXHQEORTXHV
PWLPH[ 6µORORVDUFKLYRVPRGLILFDGRVKDFHP£VGH[G¯DV
PWLPH[ 6µORORVDUFKLYRVPRGLILFDGRVKDFHPHQRVGH[G¯DV
³DPHSDWUµQ 6µORORVQRPEUHVTXHDSDUHFHQFRQHOSDWUµQLQGLFDGR
SHUPQXPHURRFWDO 6µORORVDUFKLYRVTXHDSDUHFHQFRQORVSHUPLVRVLQGLFDGRVSRUHOQ¼PHURRFWDOGDGR
XVHUXVXDULR 6µORSDUDORVDUFKLYRVGHOXVXDULRLQGLFDGR
7DEOD$2SFLRQHVGHOFRPDQGRILQG
Si se desean especificar múltiples condiciones se debe tener presente lo siguiente:

Para especificar condiciones conectadas con AND(y) basta con ponerlas en secuencia.
Para especificar condiciones conectadas con OR(o) basta con separar las dos opciones con la
opción: -o
Para realizar agrupación de condiciones se deben usar paréntesis usando: $ y $.
A.6.2. El Comando grep a detalle
Permite realizar búsquedas sobre las líneas de los archivos especificados, el patrón de
búsqueda se especifica como una expresión regular. La sintaxis es:
grep opciones expresión-regular archivos
La opción -v despliega las líneas que no aparean.
Algunos de los metacaracteres de grep son indicados en la tabla A. 17.
A.6.3. El Comando cut

Este comando permite extraer porciones de texto de la entrada estándar y el resultado es
mandado a la salida estándar.

$$,;:,1'2:6153
&$5&7(5 6,*1,),&$'2

A 3ULQFLSLRGHOLQHD

)LQGHO¯QHD

. 8QVµORFDU£FWHU
.* 0¼OWLSOHVFDUDFWHUHV
D &XDOTXLHUFDU£FWHUHVSHFLILFDGR
[-] &XDOTXLHUFDU£FWHUGHOUDQJR 7DEOD$&DUDFWHUHVGHOFRPDQGR
JUHS
La sintaxis del comando es:

cut opción archivos Se debe especificar por lo menos una de las siguientes opciones:
-c Para extraer caracteres.
-f Para extraer campos.
La opción -c permite especificar el rango de caracteres a extraer:
cut-cl-12arch
Permite extraer los caracteres del 1 al 12 de cada línea del arch especificado.
La opción -f permite extraer el número especificado enseguida, los campos están delimitados
por el carácter especificado después de la opción –d
v.g.
cut -f2 -d: archivos
cut -fl,3 -d; archivos
A.6.4. El Comando dic
Permite desplegar las diferencias entre dos archivos. Las líneas que son diferentes. La sintaxis
es: diff opciones arch1 arch2 las líneas de arch1que necesitan cambiarse se preceden con un signo < las
líneas de arch2 que necesitan cambiarse se preceden con un
signo >
La opción -b para tomar múltiples espacios como uno solo.
La opción -e despliega solo lo que necesita cambiarse en arch2 para que sea igual a arch1.
Además de desplegar las líneas diferentes en los archivos indica la acción que debe seguirse
para que sean iguales las líneas de los dos archivos, esta acción se indica con el formato: num1 acción
num2 donde num1 indica el número de línea del arch1, num2 indica el número de línea del arch2 y la
acción puede ser a(agregar) ó d(borrar) ó c(cambiar).
A.7 AIXwindows
A.7.1. Terminales virtuales
Anteriormente ya se comento el concepto de terminal virtual como la capacidad de tener el

equivalente a varias pantallas y dentro de cada una de ellas poder correr un proceso.

154 $31',&($81,;
Este concepto permite trabajar con multitasking de una forma gráfica y fácil de usar. De este
modo es posible tener un mejor control de los procesos que están corriendo.
Para crear una nueva terminal virtual basta hacer: open sh y para eliminarla presionar:
Ctrl-D para cambiar de terminal virtual basta hacer Alt+ActÍon(siguiente) ó Shift+Action (anterior).
AIXwindos es un sistema de manejo de ventanas que es superior al concepto de terminal virtual debido
a que se puede estar viendo directamente la evolución de múltiples procesos.
AIXwindows ofrece:
+ Múltiples ventanas simultáneas.

+ Múltiples procesos en el fondo(foreground) simultáneo.
+ Información gráfica y texto en cada ventana.
+ Varios tipos de letra y estilos.
+ Ventanas traslapadas y escondidas.
+ Compartición de la terminal con otras terminales virtuales.
A.7.2. Historia de Xwindows

Xwindows fue desarrollado como parte del proyecto Athena del MIT, basado en el sistema de
ventanas W de stanford, es de dominio público es posible sea el estándar IEEE-POSIX para manejo de
ventanas.
Dentro de los objetivos de diseño más importantes de Xwindows están:
1. Transparencia de RED.- Las aplicaciones de Xwindows corriendo en un CPU pueden mostrar la
salida sobre una pantalla conectada al mismo CPU o a otro CPU.
2. Independencia de Modelo y Vendedor.- Las aplicaciones de Xwindows se comunican con las
pantallas de acuerdo al protocolo X. De forma que cualquier despliegue que use dicho protocolo
se puede comunicar con la aplicación de Xwindows.
Xwindows incluye una biblioteca para ser utilizada desde el lenguaje C esta es; xlib
A.7.3. Modelo cliente-servidor
Xwindows trabaja con un modelo CLIENTE -SERVIDOR. Las diversas aplicaciones son
clientes y existe un DISPLAY SERVER (Servidor de Despliegue) que recibe las peticiones de
los clientes y las presenta en la pantalla (Hardware). Dentro de los clientes tenemos
aixterm, xclock, mwm.
El mwm (Motif Window Manager) es un cliente XI 1 que permite ser configurado por el
usuario y soporta el uso del teclado y del ratón.
Para iniciar el servidor se realiza a través del comando xinit (además corre los clientes xclock y
aixterm).
x aixterm es el emulador de terminal.
x xclock es un cliente que despliega un reloj.
A.7.4. Salida de AIXWindows
Para salir de AIXwindow se presiona Ctrl-Alt-BackSpace

$$,;:,1'2:6155
A.7.5. Ventana raíz

La parte del fondo de la pantalla se define como la ventana raíz (root window).
Señalándola es posible accesar el menú raíz. Desde el cuál es posible crear nuevas ventanas,
poner al frente o al fondo una ventana, redibujar la pantalla, reiniciar el manejador de
ventanas(mwm).
A.7.6. Distribución de una ventana
Una ventana está compuesta de las siguientes partes:
x Área de Borde.- Localizado alrededor de la ventana. Usando el ratón en esta área es posible
redimensionar la ventana.
x Área de Título.- Localizado dentro de la ventana en la parte superior. Usando el ratón en esta
área es posible mover la ventana.
x Botón de Menú de Ventana.- Localizado en la esquina superior izquierda dentro de la ventana.
Desde este menú es posible mover, redimensionar, maximizar, minimizar y cerrarla ventana.
x Botón Minimizar.- Localizado a un lado del botón de Maximizar. Permite poner la ventana
como un icono.
x Botón Maximizar.- Localizado en la esquina superior derecha. Permite poner al máximo el
tamaño de la ventana.
x Área de Menú y de cliente.- Localizada dentro de la ventana. Es dependiente de la aplicación
cliente que se esté corriendo.
A.7.7. Manejo de teclado
Algunas de las combinaciones de tecla que son útiles son ilustradas en la tabla A. 18.
T '(6&5,3&,1
$OW(VF +DFHODVLJXLHQWHYHQWDQDODYHQWDQDDFWLYD
6KLIW(VF $FWLYDHOPHQGHODYHQWDQD
DL[WHUP ,QLFLDXQQXHYRGLHQWHDL[WHUP
[FORFN ,QLFLDXQQXHYRFOLHQWH[FORFN
7DEOD$&RPDQGRVHQ;:LQGRZV
A.7.8. Manejo de AIXWindows en red
El modelo oliente-servidor de Xwindows permite trabajar en un ambiente de red de una forma

fácil. Cuando se inicia un cliente se puede especificar cuál servidor deberá ser usado. El cliente y el
servidor se comunican a través del protocolo TCP/IP. De este modo el cliente y el servidor pueden estar
en sistemas separados que se comuniquen a través de TCP/IP.
Para trabajar con clientes remotos se debe hacer lo siguiente:
x Iniciar cliente en el sistema! con: niciar AIXwindows en el sistemal con: xinit
x Permitir el acceso al sistema2 con: xhost +sistema2

156 $31',&($81,;
• Iniciar cliente en el sistema2 con:
env DISPLAY=sistemal:0.0 aixterm

NOTA: Como una alternativa al Xwindows se tiene el sistema NextStep de la compañía Next
que se puede usar dentro de las máquinas 1BM.
A.7.9. Personalización de clientes
Los clientes de AIXwindows son:
x aixterm Emulador de Terminal de AIXwindows.

x mwm Es el manejador de ventanas de OSF/Motif
x xclock Es un cliente que corre un reloj en una ventana.
x xcalc Es un cliente que corre una calculadora científica en una ventana.
x bitmap Es un cliente editor de bitmap's.
x xdt Es el escritorio(desktop) visual de AIXwindows-
x xopen Es una interface a terminales virtuales de AIXwindows.
aixterm
aixterm proporciona la emulación de terminal para programas que no usan directamente

windows. Permite cortar y pegar texto entre ventanas. Para copiar texto al buffer se marca el
texto utilizando el botón izquierdo del ratón. Para recuperar el texto se utiliza el botón de
enmedio del ratón. Para ver el menú del aixterm se presiona la tecla Ctri y el botón derecho
del ratón.
Parámetros de configuración
Para ver las opciones de cualquier cliente basta con usar el nombre del cliente con las opciones:
-help ó -keywords. Los tipos de letras y colores que se pueden usar están en los directorios
/usr/lpp/fonts y /usr/lib/Xl Í/rgb.
A.8. Sincronización / Comunicación de Procesos
A.8.1 Procesos en UNIX
UNIX usa una instalación de proceso simple pero poderosa que es muy visible para el usuario.
Todos los procesos en el sistema, excepto dos procesos básicos, los crean comandos del programa de
usuario.
El sistema operativo UNIX reconoce un total de nueve estados de proceso; estos están listados
en la tabla A-19.
El diagrama que describe esto es dado en la figura A.3.
Dentro de las características importantes tenemos:
o UNIX emplea dos estados Corriendo para indicar si el proceso se ejecuta en modo usuario o
en modo kerneL
o Se hace una distinción entre los dos estados: Listo para correr, en memoriay Adquisición
por Prioridad. En esencia, estos son el mismo estado, como lo indica la línea punteada que los

$6,1&521,=$&,1&2081,&$&,1'(352&(626 157
(67$'2 '(6&5,3&,1
8VXDULRFRUULHQGR (MHFXFLµQHQPRGRXVXDULR
.HUQHOFRUULHQGR (MHFXFLµQHQPRGRNHUQH/
/LVWRSDUDFRUUHUHQPHPRULD /LVWRSDUDFRUUHUWDQSURQWRFRPRHODVLJQDGRUGHO&38OHDVLJQHHO
'XUPLHQGRHQPHPRULD 1RVHHMHFXWDSRUHVWDUHVSHUDQGRDTXHRFXUUDXQHYHQWR(O
SURFHVRHVW£HQPHPRULD
/LVWRSDUDFRUUHUHQGLVFR (OSURFHVRHVWOLVWRSDUDFRUUHUSHURHOLQWHUFDPELDGRUVZDSSHU
WLHQHTXHWUDHUORSULPHURDPHPRULD
'XUPLHQGRHQGLVFR (OSURFHVRHVW£HVSHUDQGRODRFXUUHQFLDGHXQHYHQWR\
DGHP£VHVWDHQGLVFR
$GTXLVLFLµQSRUSULRULGDG (OSURFHVRHVW£OLVWRSDUDUHJUHVDUGHOPRGR.HUQHODOPRGRXVXDULR
SHURVHOHTXLWRHO&38SRUSULRULGDGSDUDSODQLILFDUDRWURSURFHVR
&UHDGR (OSURFHVRHVW£UHFLHQFUHDGR\QRHVW£OLVWRSDUDFRUUHU
=RPELH (SURFHVRWHUPLQRSHURGHMDLQIRUPDFLµQTXHSXHGHVHUFRQVXOWDGD
SRUHOSURFHVRSDGUH
7DEOD$(VWDGRVGHSURFHVRVHQ81;.
Llamada a sistema
interrupción
Zombie Exit Kernel corriendo Regreso Usuario
Adquisición
por prioridad Regreso
a modo
usuario
Replanificación
Adquisición por prioridad
de proceso
Sleep
Suficiente memoria
Despertar Listo para correr en
Duración en i
Regreso a
memoria Cread
Sale de disco
Sale de disco
Duración en Despertar Listo para correr en No hay suficiente

memoria
)LJXUD$'LDJUDPDGH(VWDGRVGH3URFHVRVHQ81,;

158 $31',&($81,;
une. La distinción se hace para enfatizar la manera en que se entra al estado de Adquisición
por prioridad. Cuando un proceso corre en el modo kernel (como resultado de una llamada de
supervisor, interrupción de reloj, o interrupción de E/S), llegará un momento en que el kernel
complete su trabajo y esté preparado para regresar el control al programa de usuario. En este
punto, el kernel puede decidir darle preferencia a un proceso que esté listo y es de mayor
prioridad el actual. En ese caso, el proceso en curso se mueve al estado de Adquisición
por Prioridad.
La adquisición por prioridad puede ocurrir sólo cuando un proceso esta por moverse del modo
kernel al modo usuario. Mientras un proceso corre en el modo kernel, no puede ser desplazado. Esto
hace que UNIX no sea adecuado para procesamiento en tiempo real.
Procesos de sistema
Dos procesos son únicos en UNIX. El proceso O es un proceso especial que se crea cuando el
sistema es arrancado, este proceso es el intercambiador (swapper). Además el proceso O produce el
proceso 1, llamado init. Los demás procesos del sistema tienen al proceso 1 como ancestro. Cuando un
usuario interactivo nuevo se registra en el sistema, el proceso 1 le crea un proceso de usuario. Después,
el programa de usuario puede crear procesos hijos usando fork, cualquier aplicación puede estar
formada por varios procesos.
Información de los procesos
Un proceso en UNIX es un conjunto bastante complejo de estructuras de datos que proporciona

al sistema operativo toda la información necesaria para manejar y despachar procesos. La tabla A.20.
presenta los elementos de la imagen de un proceso.
La tabla A.21 presenta una entrada de la tabla del proceso.
El área de usuario, o área U, contiene información adicional de control del proceso que necesita
el kernel sólo cuando ejecuta en el contexto de este proceso, esto se indica en la tabla A.22.
A.8.2. Creación de un proceso

La creación de un proceso en UNIX se realiza mediante la llamada al kernel
denominada fork. Cuando un proceso ejecuta un fork, el sistema operativo ejecuta las
siguientes funciones:
1. Asigna al nuevo proceso, una entrada en la tabla de procesos.
2. Asigna un identíficador de proceso único al proceso hijo.
3. Hace una copia de la imagen del proceso del padre, con excepción de cualquier memoria
compartida (pues solo se utiliza la copia del padre por los hijos).
4. Aumenta los contadores de los archivos que posee el padre, para reflejar que un proceso
adicional ahora también posee esos archivos.
5. Asigna el proceso hijo al estado Listo para correr.
6. Regresa el número de identíficador del hijo al proceso padre y un valor cero al proceso hijo
(tanto padre como hijo continúan la ejecución después del fork).

$6,1&521,=$&,1&2081,&$&,1'(352&(626 159
&217(;72 ,7(0 '(6&5,3&,1

868$5,2 7H[WRGHOSURFHVR ,QWUXFFLRQHVGHP£TXLQDVHMHFXWDEOHVGHOSURJUDPD
868$5,2 'DWRVGHOSURFHVR 'DWRVDFFHVLEOHVSRUHOSURJUDPDGHHVWHSURFHVR
868$5,2 6WDFNGHOXVXDULR &RQWLHQHORVDUJXPHQWRVYDULDEOHVORFDOHV\DSXQWDGRUHV$ODV
IXQFLRQHVHMHFXW£QGRVHHQPRGRXVXDULR
868$5,2 0HPRULDFRPSDUWLGD /DPHPRULDFRPSDUWLGDFRQRWURVSURFHVRVXVDGDSDUDODFRPXQLFDFLµQ
LQWHUSURFHVRV
5(*,6752 &RQWDGRUGHOSURJUDPD 'LUHFFLµQGHODVLJXLHQWHLQVWUXFFLµQDVHUHMHFXWDGDHVWDSXHGHVHUGHO
.HUQHORGHOSURJUDPDGHXVXDULR
5(*,6752 5HJLVWURGHHVWDGRGHO 7DPEL«QFRQRFLGRFRPRHOUHJLVWURGHODVEDQGHUDVFRQWLHQHOD
3URFHVDGRU LQIRUPDFLµQUHODWLYDDOHVWDGRGHOSURFHVDGRU
5(*,6752 $SXQWDGRUGH6WDFN $SXQWDDOWRSHGHO6WDFN\DVHDHOGHOXVXDULRRGHONHUQHOGHSHQGLHQGR
GHOPRGRHQHOTXHVHHVW«FRUULHQGR
5(*,6752 5HJLVWURVGHSURSµVLWRJHQHUDO &RQWLHQHODLQIRUPDFLµQUHODWLYDDORVUHJLVWURVDGLGRQDOHVGHO
SURFHVDGRU
6,67(0$ (QWUDGDHQODWDEODGHSURFHVRV 'HILQHHOHVWDGRGHXQSURFHVRDFFHVLEOHSRUHOVLVWHPDRSHUDWLYR
6,67(0$ UHD8£UHDGHXVXDULR ,QIRUPDFLµQGHFRQWUROTXHQHFHVLWDVHUDFFHVDGDSRUHOFRQWH[WRGHO
SURFHVR
6,67(0$ 7DEODGHUHJLµQGHSUHSURFHVR 'HILQHHOPDSHRGHODVGLUHFFLRQHVYLUWXDOHVDGLUHFFLRQHVUHDOHV
DGHP£VGHFRQWHQHUORVSHUPLVRVGHDFFHVRVROROHFWXUDOHFWXUD
HVFULWXUD\OHFWXUDHMHFXGµQ
6,67(0$ 6WDFNGHO.HUQHO &RQWLHQHHOVWDFNGHO.HUQHOFXDQGRORVSURFHVRVVHHMHFXWDQHQPRGR
.HUQHO
7DEOD$,P£JHQHVGHXQSURFHVR
ITEM '(6&5,3&,1
(VWDGRGHOSURFHVR 'HILQHHHVWDGR DFWXDOGHOSURFHVR
$SXQWDGRUHV $O£UHDGHXVXDULR\ODPHPRULDGHOXVXDULRWH[WRGDWRVVWDFN
7DPD³RGHOSURFHVR 3HUPLWHGHILQLUHOHVSDFLRTXHVHGHEHDVLJQDUDOSURFHVR
LGHQWLILFDGRUGHOXVXDULR (OLGHQWLILFDGRUGHOXVXDULRTXHFUHµHOSURFHVR
,GHQWLILFDGRUHVGHSURFHVR &RQWLHQHHOLGHQWLILFDGRUGHOSURFHVRSDGUH\GHOPLVPRSURFHVR
'HVFULSWRUGHOHYHQWR 7LHQHLPSRUWDQFLDFXDQGRHOSURFHVRHVW£GXUPLHQGRHVSHUDQGRXQHYHQWRFXDQGRHO
HYHQWRRFXUUHHSURFHVRHVWUDQVIHULGRDOHVWDGROLVWRSDUDFRUUHQ
3ULRULGDG 1¼PHURXVDGRSRUHODVLJQDGRUGH&38SDUDUHDOL]DUODSODQLILFDFLµQ
6H³DOHV /LVWDODVVH³DOHVTXHKDQVLGRPDQGDGDVDOSURFHVR
7HPSRUL]DGRUHV 8VDGRSDUDPDQGDUVHDOHVHQWUHSURFHVRV\OOHYDUHOWLHPSRGHHMHFXFLµQGHOSURFHVR
/LJD33OLQN $SXQWDGRUDOVLJXLHQWHSURFHVRHQODFRODGHOLVWRSDUDFRUUHUTXHVHUHMHFXWDGRWLHQH
VHQFLGRVLHOSURFHVRHVW£OLVWRSDUDFRUUHU
(VWDGRGHODPHPRULD ,QGLFDVLHOSURFHVRHVW£HQPHPRULDSULQFLSDORHQGLVFR
7DEOD$(QWUDGDHQODWDEODGHSURFHVRV.

160 $31',&($81,;
,7(0 '(6&5,3&,1
$SXQWDGRUDODWDEODGHOSURFHVR ,QGLFDODHQWUDGDTXHFRUUHVSRQGHDO£UHD8
,GHQWLILFDGRUHVGHXVXDULR ,GHQWLILFDGRUHVGHXVXDULRGHORVSURFHVRV
7HPSRUL]DGRUHV 3DUDOOHYDUHOWLHPSRTXHORVSURFHVRVVHKDQHMHFXWDGRHQPRGR
XVXDULR\HQPRGRNHUQHO
$UUHJORPDQHMDGRUGHVH³DOHV 3DUDFDGDWLSRGHVHDOTXHUHFLEDHOSURFHVRLQGLFDFRPRVHYDD
PDQHMDULJQRUDUWHUPLQDURHMHFXWDUXQDUXWLQD
7HUPLQDOGHFRQWURO ,QGLFDODWHUPLQDOGHHQWUDGDGHOSURFHVR
&DPSRGHHUURU 5HJLVWUDORVHUURUHVDOHMHFXWDUXQDOODPDGDDOVLVWHPD
9DORUGHUHJUHVR &RQWLHQHHOUHVXOWDGRGHODVOODPDGDVDOVLVWHPD
3DU£PHWURVGH(6 'HVFULEHODVFDUDFWHU¯VWLFDVSDUDUHDOL]DUWUDQVIHUHQFLDVFRQ
3DU£PHWURVGHDUFKLYRV /RVGLUHFWRULRVTXHGHILQHQHODPELHQWHGHOSURFHVR
7DEODGHGHVFULSWRUHVGHDUFKLYRVGHXVXDULR /OHYDHOFRQWUROGHORVDUFKLYRVTXHKDDELHUWRHOXVXDULR
&DPSRVO¯PLWH 5HVWULQJHHWDPD³RGHXQSURFHVR\HOWDPD³RGHORVDUFKLYRV
&DPSRVGHSHUPLVRV 'HILQHQORVSHUPLVRVGHORVDUFKLYRVTXHHOSURFHVRFUHD
7DEOD$,QIRUPDFLµQGHO£UHD8GHXQSURFHVR
Todo esto se realiza en el modo kernel en el proceso padre. Cuando el kernel ha completado
estas funciones, el despachador (asignador del CPU) puede hacer alguna de las opciones siguientes:
1. Seguir ejecutando el proceso padre. Regresa el control al modo usuario en el punto de la

llamada fork del proceso padre.
2. Transfiere el control al proceso hijo. El proceso hijo empieza la ejecución en el mismo
punto en el código que el proceso padre, es decir, en el regreso de la llamada al fork.
3. Transfiere el control a otro proceso. Los procesos padre e hijo se quedan en el estado listo
para correr.
Un punto importante es que padre e hijo ejecutan el mismo código. La única diferencia es el valor de
regreso del fork, si el valor es cero, entonces este es el proceso hijo y puede ejecutarse una llamada a un
programa apropiado para continuar la ejecución. Si el valor no es cero, entonces este es el proceso
padre y puede continuar ia ejecución del programa original.
A.9. Comunicación Interprocesos

UNIX proporciona varios mecanismos para comunicación y sincronización interprocesos,
los más importantes son:
xTubos(Pipes).
xMensajes.
xMemoria compartida.
xSemáforos.
xSeñales.

$&2081,&$&,1'(,17(5352&(626 161
Los pipes, los mensajes y la memoria compartida se usan para la comunicación entre los procesos,
mientras que los semáforos y las señales se usan para la sincronización entre procesos.
A.9.1. Pipes
Una de las características más relevantes de UNIX es el concepto de PIPE. Desarrollado a partir del
concepto de corrutinas, un pipe es un buffer circular que permite a dos procesos comunicarse usando el
modelo productor / consumidor, esto es la primer información escrita por un proceso es la primera en
ser leída por el otro(PEPS o PIFO).
Cuando se crea un pipe, se le da un tamaño fijo en bytes. Se manejan automáticamente los casos de
LLENO y VACIO, es decir si se intenta escribir cuando está lleno se BLOQUEA al proceso y si se
intenta leer cuando está vacío se BLOQUE al proceso que quiso leer. Además automáticamente maneja
el sistema operativo la exclusión mutua, es decir solo un proceso a la vez accesa el PIPE.
Existen tres tipos de pipes; con nombre(también denominados FIEOS), sin nombre y los pipes de flujo
(stream pipes). Sólo los procesos relacionados pueden compartir pipes sin nombre, mientras que los
procesos no relacionados pueden compartir sólo tubos con nombre, los stream pipes pueden ser con
nombre o sin nombre.
Pipes sin Nombre
La forma de crear un pipe es a través de la función: int pipe (int filedes [2]) La función regresa
dos decriptores de archivos, filedes[0] está abierto para lectura y filedes[ 1] está abierto para escritura.
Desde el punto de vista de un proceso un pipe puede ser visto como un archivo al que se le escribe
usando filedes[I] y se lee de el usando filedes[OJ. Esto puede ver en la gráfica A.4.
3URFHVRGHXVXDULR

IG>@IG>@

NHUQHO

3LSH

)LJXUD$8QSLSHVLQQRPEUH

162 $31',&($81,;

Realmente no es muy útil que el mismo proceso lea y escriba del pipe, lo que es más útil es utilizar el
pipe para permitir comunicar a un proceso padre con un hijo, v.gr. si el proceso padre después de crear
el pipe realiza un fork se tendrá la estructura de comunicación ilustrada en la figura A.5.
3DGUH +LMR
SS 3S
IG>@IG>@ IG>@IG>@

3LSH

3LSH

.HUQHO

)LJXUD$&RPXQLFDFLµQHQWUHXQSURFHVRSDGUH\XQSURFHVRKLMRDWUDY«VGHXQSLSH.
Con frecuencia se utilizan las funciones popen y pclose para facilitar el manejo de los pipes.
El formato de la función popen es:
FILE *popen(const char *cmdstring, const char *type)
y realiza un fork seguido de un exec para ejecutar el comando cmdstring, si type es “r” el
apuntador de archivo queda conectado a la salida estándar de cmdstring si type es “w” el apuntador de
archivo queda conectado a la entrada estándar de cmdstring.
El formato de la función pelóse es el siguiente:
int pclose(FILE *fp)
su función es cerrar la E/S estándar asociada al cmdstring.
Pipes con nombre (FIFOs)
Los pipes con nombre pueden ser usados entre procesos relacionados siempre y cuando un
ancestro común haya creado el pipe. Utilizando los pipes(fifos) es posible que procesos no relacionados
puedan intercambiar datos.
El formato para crear un pipe con nombre o fifo es el siguiente:
int mkfifo (const char *pathname, mode-t mode)

$&2081,&$&,1'(,17(5352&(626 163
La creación de un fifo es similar a la creación de un archivo. Una vez creado el fifo se puede abrir
usando la función open (las funciones normales de manejo de archivos como:
cióse, read, write, unlink,... funcionan con los fifos).
Al abrir el fifo y no especificar la bandera de nobloqueo (0-NONBLOCK) puede ocurrir lo siguiente:
* Si se abre en modo solo lectura (read-only) se bloquea al proceso hasta que otro proceso abra el fifo
para escritura.
* Si se abre en modo solo escritura (write-only) se bloquea al proceso hasta que otro proceso abra el
fifo para lectura.
Al abrir el fifo y especificar la bandera de nobloqueo (0-NONBLOCK) puede ocurrir lo siguiente:
* Si se abre en modo solo lectura (read-only) inmediatamente continua el proceso.
* Si se abre en modo solo escritura (write-only) regresa el error ENXIO si no existe un proceso que
haya abierto el fifo para lectura.
Si se escribe sobre un fifo que no está abierto para lectura por ningún proceso se genera la señal
SIGPIPE, y cuando el último escritor cierra el FIFO se genera un FIN DE ARCHlVO(eof) para el
lector del fifo.
Es común que se tengan múltiples escritores para un fifo por lo cuál es importante conservar las
escrituras atómicas, esto se logra a través de la constante PIPE-BUF que especifica la cantidad máxima
de datos que debe ser escrita en forma atómica, si todos los escritores escriben menos que esta cantidad
se garantiza que las escrituras son atómicas.
Los fifos se utilizan principalmente para:
* Comunicar comandos sin necesidad de utilizar archivos temporales.
* Aplicaciones cliente-servidor para pasar datos entre los clientes y el servidor.
La gráfica A.6 ilustra la forma de manejar los fifos para aplicaciones cliente-servidor.
En este caso los clientes se comunican con el SERVIDOR a través del fifo conocido por todos y
pueden mandarle al servidor su identificador de proceso, el proceso SERVIDOR se comunica con un
CLIENTE específico creando un FIFO particular para ese cliente, de forma tal que a través de los fifos
específicos el SERVIDOR puede mandar mensajes que serán leídos por los clientes(que saben por su
identificador de que fifo leer).
PIPEs FuIl-Duplex o PIPEs de Flujo(Stream Pipes)
Un stream pipe puede ser sin nombre o con nombre pero tiene la característica de ser bidireccional, esto
se ilustra en la figura A.7.
La operación para crear un stream pipe es s-pipe, una característica importante de los stream pipes es
que en general son más rápidos que el uso de colas de mensajes.
Características comunes entre mensaje, semáforos y memoria compartida
En UNIX existen similitudes entre los tres mecanismos de comunicación/sincronización mensajes,

semáforos y memoria compartida, cada estructura IPC (InterProcess Conununica-tion) es referenciada
con un identificador de tipo integerno negativo. Para usar el mecanismo deseado lo único que se
requiere es conocer su identificador.

164 $31',&($81,;
6HUYLGRU
),)2 ),)2
(63&7(, (63&7(1
),)2
&RQRFLGR
SRUWRGRV
...
...
&OLHQWH&7(, &OLHQWH&7(1
)LJXUD$),)2VSDUDLPSOHPHQWDUXQDDSOLFDFLµQFOLHQWHVHUYLGRU

3URFHVRGH
XVXDULR
IG>@IG>@
NHUQHO
6WUHDPSLSH
)LJXUD$'LDJUDPDGHOXVRGHXQ6WUHDPSLSH

$&2081,&$&,1'(,17(5352&(626 165
Cada mecanismo tiene asociado una estructura de datos que lo define, esta estructura es creada
utilizando las llamadas msgget, shmget o semget en esta llamada se debe especificar una llave (key)
cuyo tipo de datos es key-t y está definido en < sys/types.h >, esta llave (key) es utilizada para crear su
identificador dentro del kernel.
Existen varios formas en que los procesos servidor y cliente utilicen la misma estructura IPC:
x El servidor puede crear una nueva estructura IPC especificando la llave IPC-PRIVATE y
almacenar el identificador regresado (por ejemplo en un archivo) en donde el cliente puede leer
dicho identificador. La desventaja de esto es que se debe usar el sistema de archivos para
realizar la comunicación.
x Una forma muy utilizada es que el padre realice la creación de la estructura especificando IPC-
PRIVATE y después realice un fork heredando a su hijo el identificador del IPC.
Para referirse a una estructura IPC ya creada nunca se debe especificar la llave IPC-PRIVATE, pues se
crearía una nueva estructura, en vez de esto se debe usar el identificador de la estructura IPC y utilizar
solo las operaciones de manipulación y no de creación. Para crear una nueva estructura siempre se debe
utilizar una llave con IPC-CREAT haciendo OR con IPC-EXCL.
Estructura de permisos
Con cada estructura IPC está asociada una estructura que define los permisos y el propietario:
struct ipc-perm {
uid_t uid; /* Ident del usuario propietario*/ gid-t gid; /* Ident del
grupo del propietario*/
uid-t cuid; /* Ident del usuario creador */
gid-t cgid; /* Ident del grupo del creador */
mode-t mode; /* Modo de acceso*/
u-long seq; /* Número de Secuencia del slot */
key-t key; /* Llave */
}
Todos los elementos de la estructura son imcializados cuando se crea la estructura IPC excepto seq. Se
pueden modificar después los campos de uid, gid y mode a través de las operaciones msgcti, semctl o
shmcti, para que un proceso pueda modificar esto, el proceso debe ser el creador de la estructura IPC o
el superusuario. Los valores de mode especifican los permisos de la estructura IPC se dan en la tabla
A.23.
3HUPLVR 0HQVDMHV 6HP£IRURV 0HPRULDFRPSDUWLGD

/HFWXUD 06*5 6(05 6+05
(VFULWXUD 06*: 6(0: 6+0:
7DEOD$3HUPLVRVGHODHVWUXFWXUD,3&
Estos valores pueden ser definidos a nivel usuario, grupo y los otros.

166 $31',&($81,;
Un problema fundamental de las estructuras IPC es que son validos en todo el sistema y la
estructura no es borrada al terminar el proceso. A menos que se borre específicamente a través de un
llamado a ipcrm, en cambio con los pipes al terminar el último proceso que hace referencia a él se borra
el pipe.
Mensajes
Un mensaje es un bloque de texto con tipo. UNIX proporciona las operaciones msgget, msgcti,
msgsnd y msgrcv para realizar el paso de mensajes. A cada proceso, se le asocia una cola de mensajes,
la cual funciona como un buzón.
El que envía el mensaje especifica el tipo con cada mensaje enviado y el receptor puede usarlo
como un criterio de selección. El receptor puede recuperar mensajes completos de acuerdo al orden de
llegada(PEPS) o de acuerdo al tipo. Un proceso se suspenderá cuando trata de enviar un mensaje a una
cola llena. Un proceso también se suspenderá cuando trata de recibir un mensaje de una cola vacía. Si
un proceso intenta leer un mensaje de un cierto tipo y no se puede hacer, el proceso no es suspendido.
Cada cola de mensajes tiene la estructura de datos siguiente:
struct msqid-ds{
struct ipc-perm msgperm; /* Estructura de Permisos */
struct msg *msg-first; /* Apuntador al Primer mensaje */
struct msg *msgJast; /* Apuntador al Ultimo mensaje */
ulong msg-cbytes; /* Número de Bytes Actual en la cola */
ulong msg-qnum; /* Número de mensajes Actual en la cola */
ulong msg-qbytes; /* Número máximo de bytes de la cola */
pid-t msg-Jspid; /* Ident. del últ. proceso hizo msgsndQ */
pid-t msgJrpid; /* Ident. del últ. proceso hizo msgrcvQ */
time-t msg-stime; /* Hora del últ. msgsnd() */
timeJ msg-rtime; /* Hora del últ. msgrcvQ */
time-t msg-ctime; /* Hora del últ. cambio */
}
Algunas constantes que definen la operación de las colas de mensajes especificando el
tamaño en bytes y en número de mensajes son: MSGMAX, MSGMNB, MSGMNI y
MSGTQL.
msgget El formato de la operación msgget es:

int msgget (key-t key, int flag);
Dependiendo de los valores especificados en key se crea una nueva estructura de mensaje
o se conecta a una creada previamente. Si se crea una nueva estructura se inicializan los valores
de msqid-ds de la siguiente forma:
x La estructura ipc-perm es inicializada y el campo mode de esta estructura se define de
acuerdo a los valores de flag.
x Los campos msg-qnum, msgJspid, msg-irpid, insg-stime, msg-Jlime son puestos en cero.
x El campo msg-ctime es puesto a la hora actual del sistema.

$&2081,&$&,1'(,17(5352&(626 167
x El valor de msg-qbytes se define de acuerdo al limite del sistema.

Si la operación msgget es exitosa regrese un identificador entero no-negativo que define la cola de los
mensajes, si no es exitosa la operación regrese un -1.
msgctl La operación msgcti regresa O si es exitosa y -1 de otra forma, la sintaxis es la siguiente:

int msgcti (int msqid, int cmd, struct msqid-ds *buf);
El valor de cmd define la operación que se realizará, esto se indica en la tabla A.24.
9$/25GHFPG '(6&5,3&,1
,3&67$7 /HHODHVWUXFWXUDLGHQWLILFDGDSRUPVJLG\ODDOPDFHQDHQODHVWUXFWXUDDSXQWDGDSRUEXI
,3&B6(7 'HILQHORVFDPSRVPVJBSHUPXLGPVJSHUPJLGPVJSHUPXLG\PVJBTE\WHVGHODFROD
GHPHQVDMHVGHILQLGDSRUPVJLGWRPDQGRORVYDORUHVGHODHVWUXFWXUDDSXQWDGDSRUEXI
3DUDTXHXQSURFHVRSXHGDUHDOL]DUHVW£RSHUDFLµQHOLGHQWLILFDGRUGHOSURFHVRGHEHVHU
PVJBSHUPFXLGµPVJBSHUPXLGRXQSURFHVRVXSHUXVXDULR6µORHOSURFHVR
VXSHUXVXDULRSXHGHLQFUHPHQWDUHOYDORUGHPVJBTE\WHV
,3&B50' %RUUDODFRODGHPHQVDMHVGHOVLVWHPD\FXDOTXLHUPHQVDMHHQHOOD/RVSURFHVRVTXH
HVW£QXVDQGRWRGDY¯DODFRODUHFLELU£QXQHUURU(,'50HQODVLJXLHQWHRSHUDFLµQTXHVH
UHDOLFH(VWDRSHUDFLµQVµORVHSXHGHUHDOL]DUSRUXQSURFHVRFX\R,GHQWLILFDGRU
FRUUHVSRQGDDDPVJBSHUPFXLGµPVJBSHUPXLGRSRUHOSURFHVRVXSHUXVXDULR

7DEOD$&RPDQGRVGHODRSHUDFLµQPVJFWL.
msgsnd La operación msgsnd tiene la sintaxis siguiente:
int msgsnd(int msgmsqid, const void *ptr, size_t nbytes, int flag);
Regresando O si es exitoso y -1 sino.
Cada mensaje queda formado por un long integer que define el tipo del mensaje, el número que
define la longitud del mensaje(nbytes) y los datos del mensaje, ptr apunta a un long integer que
contiene un valor positivo que define el tipo del mensaje seguido del mensaje en sí, como ejemplo si
los mensajes son de tamaño 512 se tiene:
struct mensaje{
long tipo; /* Valor positivo del tipo de mensaje)*/
char conten; /* Datos del mensaje definidos por nbytes */
El valor de tipo puede ser usado por el receptor para leer los mensaje en orden diferente al de
entrada (PEPS).
Si se especifica IPC_NOWAIT y se excede el número de mensajes o el tamaño en bytes en la
cola msgsnd regresa inmediatamente indicando el error EAGAIN.
Si no se especifica IPC_NOWAIT y se excede el número de mensajes o el tamaño en bytes de
la cola se bloque al proceso hasta que:
x Haya espacio para el mensaje.

x La cola sea borrada del sistema, con lo que se regresa el error EIDRM.
x Se reciba una señal, con lo cuál se regresa el error EINTR.

168 $31',&($81,;
msgrcv La sintaxis de msgrcv es:

int msgrcv(int msqid,void *ptr, size_t nbytes,
long type, int flag);
Regresa O si es exitosa y -1 de otra forma.
Si se especificó en flag MSG_NOERROR se regresa el mensaje truncado en caso de que el
mensaje leído sea más grande que n-bytes (sin indicar error). Si no se especifico en flag
MSG_NOERROR y el mensaje es más grande que n_bytes se regresa el error E2BIG y el mensaje
queda en la cola(no es retirado).
El valor de type permite especificar que mensaje recibir, las opciones se ilustran en la tabla
A.25.
9$/25'(W\SH '(6&5,3&,1
6HUHJUHVDHOSULPHUPHQVDMHGHODFROD
! 6HUHJUHVDHOSULPHUPHQVDMHFX\RYDORUGHOWLSRVHDLJXDODOHVSHFLILFDGR
(OSULPHUPHQVDMHFX\RYDORUGHOWLSRVHDPHQRURLJXDODOYDORUDEVROXWR
GHOHVSHFLILFDGRHVHOTXHVHUHJUHVD}
7DEOD$2SFLRQHVSDUDHVSHFLILFDUTXHPHQVDMHUHFLELU
Si se especifica IPC-NOWAIT y se especifica un tipo de mensaje(diferente de cero), se regresa

el error ENOMSG al no existir ningún mensaje del tipo requerido.
Si no se especifica IPC-NOWAIT y no hay disponible ningún mensaje con el tipo requerido se
bloque al proceso hasta que:
x Un mensaje del tipo especificado esté disponible.

x La cola sea borrada del sistema y se regresa el error EIDRM.
x Se mande una señal, con lo cuál se regresa el error de EINTR.
Memoria compartida
La forma más rápida de comunicación interprocesos que proporciona UNIX es la memoria
compartida, la cual es un bloque común de memoria virtual, compartida por múltiples procesos.
Los procesos leen y escriben en la memoria compartida usando las mismas instrucciones de
máquina que usan para leer y escribir en otras partes de su espacio de memoria virtual. El permiso
para un proceso es solo leer o leer-escribir, determinado con base en cada proceso. La exclusión
mutua no es soportada directamente por la memoria compartida y debería ser soportada por otro
mecanismo por ejemplo usando semáforos.
El kernel mantiene la siguiente estructura para cada área de memoria compartida:
struct shnid ds {
struct ipc_perm shm_perm; /* Permisos */
struct anon_map *shm_map; /* Apuntador del kernel */
int shm_segsz; /* Tamaño del segmento en bytes */
ushort shm_lkcnt; /* # veces que se ha bloquedo el segmento */
pid_t shmJpid; /* Ident. del proceso de últ. shmopQ */
pid_t shm-cpid; /* Ident. del proceso creador */
ulong shm_nattch; /* # actual de enlaces a mem. compartida */
$&2081,&$&,1'(,17(5352&(626 169
ulong shm_cnattch; /* Solo usado por shminfo */

time_t shm_atime; /* Hora de último enlace(attach) */
time_t shm_dtime; /* Hora de último desenlace(dettach) */
time_t shm_ctime; /* Hora de último cambio. */
}
Las constantes SHMMAX, SHMMIN, SHMMNI y SHMMSEG definen los tamaños de los
segmentos y el número de ellos.
shmget La función para obtener un identificador de memoria compartida es shmget, cuya sintaxis es:
int shmget(key_t key, int size, int flag);

Cuando se crea un nuevo segmento se inicializan los siguientes elementos de shmid_ds:
x Se inicializa la estructura ipc_perm como ya se definió para los mensajes y el valor de
ipc_perm.mode son definidos por el valor de flag define los permisos de lectura y escritura para
los usuario, grupos y los otros.
x Los campos shmJpid, shm_nattch, shm_atime y shm-dtime son puestos en cero.
x El campo shm_ctime se define con la hora actual.
El valor de size define el tamaño mínimo del segmento deseado. Si se hace referencia a un
segmento ya creado(desde un cliente) se puede especificar size en cero.
shmctl La operación shmetl permite controlar diversas opciones de la memoria compartida, la

sintaxis de esta operación es :
int shmctl(int shmid, int cmd, struct shmid-ds *buf) El parámetro especifica alguno de los valores
ilustrados en la tabla A.26.
9$/25 '(6&5,3&,1
,3&67$7 /HHODHVWUXFWXUDVKPLGVSDUDHOVHJPHQWRLQGLFDGRJXDUG£QGRORHQODHVWUXFWXUDDSXQWDGDSRU
EXI
,3&6(7 'HILQHORVFDPSRVVKPSHUPXLGVKPSHUPJLGVKPSHUPPRGHGHDFXHUGRDORVYDORUHV
GHILQLGRVHQODHVWUXFWXUDDSXQWDGDSRUEXI(VWHFRPDQGRVRORORSXHGHHMHFXWDUHOSURFHVRFRQ
LGHQWLILFDGRULJXDODVKPBSHUPXLGVKPSHUPFXLGRHOSURFHVRVXSHUXVXDULR
,3&50' %RUUD HO VHJPHQWR GH PHPRULD FRPSDUWLGD GHW VLVWHPD (O VHJPHQWR QR VH ERUUD KDVWD TXH HO
¼OWLPRSURFHVRHQOD]DGRDO£UHDGHPHPRULDFRPSDUWLGDVHGHVHQODFHSHURQRVHSHUPLWHQQXHYRV
HQODFHV3DUDTXHVHSXHGDUHDOL]DUHOFRPDQGRHOSURFHVRTXHORHMHFXWDGHEHWHQHULGHQWLILFDGRU
LJXDODVKPASHUPXLGVKPSHUPFXLGRHOSURFHVRVXSHUXVXDULR
6+0/2&. %ORTXHD HO VHJPHQWR GH PHPRULD FRPSDUWLGD (VWH FRPDQGR VµOR VH SXHGH HMHFXWDU SRU HO
VXSHUXVXDULR
6+0--1/2&. 'HVEORTXHDHOVHJPHQWRGHPHPRULDFRPSDUWLGD(VWHFRPDQGRVRORORSXHGHUHDOL]DUHOSURFHVR
VXSHUXVXDULR
7DEOD$9DORUHVGHFPGGHQWURGHVKPFWO.
shmat Una vez que se ha creado el segmento de memoria compartida un proceso se enlaza a él con:

170 $31',&($81,;
void *shmat (int shmid, void *add, int flag)

La dirección a la cuál se enlaza el proceso que llama depende de el argumento addr y del valor
de flag:
x Si addr es cero el segmento al que se enlaza es la primer direción disponible seleccionada por
el kernel.(Esto es lo recomendado).
x Si addr no es cero y no se especifica SHM_RND, se enlaza al segmento de acuerdo a la
dirección especificada.
x Si addr no es cero y se especifica SHM_RND(de ROUND, redondear), se conecta al addr
redondeándolo de acuerdo a la alineación definida(normal mente múltiplo de dos, esto se
define por SHMLBA)
shmdt La operación shmdt permite desenlazarse de un área de memoria compartida (sólo se borra con
shmctl) la sintaxis de esta operación es:
int shmdt(void *addr);

El valor de addr debe ser el que se regreso en la llamada a shmat.
Semáforos
Las llamadas al sistema de semáforos en el sistema UNIX son una generalización de las
primitivas P y V. Pues pueden realizarse varias operaciones de manera simultánea y el aumento y
decremento de las operaciones pueden ser valores mayores que uno. El kernel hace todas las
operaciones requeridas en forma atómica; ningún otro proceso puede accesar el semáforo sino hasta
que se terminan todas las operaciones.
Un semáforo consta de los siguientes elementos:
x Valor actual del semáforo.

x ID del último proceso que operó en el semáforo.
x Número de procesos esperando que el valor del semáforo sea mayor que el valor actual.
x Número de procesos esperando que el valor del semáforo sea 0.
Asociadas con el semáforo, están las colas de procesos suspendidos en ese semáforo.
En realidad, los semáforos se crean en conjuntos y un conjunto consta de uno o más semáforos.
Existe una llamada de sistema semctl que permite establecer todos los valores del semáforo en el
conjunto, al mismo tiempo. Además, existe una llamada de sistema semop que toma como argumento
una lista de operaciones del semáforo, cada una definida sobre uno de los semáforos en un conjunto.
Cuando se hace esta llamada, el kernel ejecuta las operaciones indicadas una a la vez. Para cada
operación, la función real la especifica el valor sem_op.
Las posibilidades son las siguientes:
x Si sem_op es positivo, el kernel aumenta el valor del semáforo y despierta todos los procesos
esperando que el valor del semáforo aumente.
x Si sem_op es O, el kernel comprueba el valor del semáforo. Si es O continua con las otras
operaciones en la lista; de otra manera, aumenta el número de procesos esperando que este
semáforo sea O y suspende el proceso en caso de que el valor del semáforo sea igual a 0.

$&2081,&$&,1'(,17(5352&(626 171
x Si sem_op es negativo y su valor absoluto es menor que o igual al valor del semáforo, el kernel
añade sem_op (un numero negativo) al valor del semáforo. Si el resultado es O, el kernel
despierta todos los procesos esperando que el valor del semáforo sea igual a O.
Esta generalización del semáforo proporciona mucha flexibilidad en la sincronización y comunicación

de los procesos.
semget La operación semget permite realizar la creación del semáforo pero no su inicialización (para
ello se debe usar la operación semctl). Y se debe tomar en cuenta que el semáforo no es borrado cuando
el proceso que lo creo termina, para ello es necesario hacerlo a través de semctl.
Internamente se maneja la siguiente estructura de los semáforos:
struct semid_ds {
struct ipc_perm sem_perm; /* Definición de permisos */
struct sem *sem_base; /* Apuntador al primer semáforo del conjunto */
ushort sem_nsems; /* # de semáforos en el conjunto */
time_t sem_otime; /* Hora de última operación semop() */
time_t sem_ctime; /* Hora de última modificación */
}
sem_base es un apuntador manejado en el kernel que apunta a un arreglo de estructuras sem:
struct sem {
ushort semval; /* Valor del semáforo, siempre MAYOR O IGUAL A CERO */
pid_t sempid; /* Ident. del proceso que hizo últ. operación */
ushort semcnt; /* # de procesos esperando semval > valor actual*/
ushort semzcnt; /* # de procesos esperando que semval = O */
}
Algunas constantes que definen la operación de los semáforos respecto al número máximo de
semáforos en el conjunto y sus valores son: SEMVMX, SEMAEM, SEMMNI, SEMMNS, SEMMSL,
SEMMNU. SEMUME y SEMOPN.
La sintaxis de la operación semget es:
int semget(key_t key, int nsems, int flag);
Al crear un semáforo se inicializan los siguiente Ítems de la estructura semid_ds:
x Se inicializa la estructura ipc_perm, definiéndose el campo de mode de acuerdo a flag.

x sem_otime es puesto en cero.
x sem_ctime se pone en la hora actual.
x sem_nsems toma el valor de nsems.
Si se hace referencia a un semáforo previamente creado se especifica nsems en cero.
semctl La operación que permite entre otras cosas realizar la inicialización es semctl, sus sintaxis es:
int semctl (int semid, int semnum, int cmd, unión semun arg);

172 $31',&($81,;
El último argumento está definido como:

unión semun {
int val; /* Especificado para SETVAL */
struct semid_ds *buf; /* Especificado para IPC_STAT y IPC_SET */
ushort *array; /* Especificado para GETALL y SETALL */
Los valores de la tabla ?? definen los comandos que se deben especificar en cmd.( En el caso de
referirse a un solo semáforo se debe especificar un número entre O y nsems-1)
&20$1'2 '(6&5,3&,1
,3&B7$7 /HHODHVWUXFWXUDGHVHPLGGV\ODDOPDFHQDHQODHVWUXFWXUDDSXQWDGDSRUDUJEXI
,3&B6(7 'HILQHORVFDPSRVVHPBSHUPXLGVHPBSHUPJLG\VHPBSHUQUPRGHGHDFXHUGRDYDORUHVTXHVHWLHQHQHQOD
HVWUXFWXUDDSXQWDGDSRUDUJEXW3DUDTXHVHSXHGDUHDOL]DUHVWDRSHUDFLµQHOLGHQWLILFDGRUGHOSURFHVRGHEH
FRLQFLGLUFRQVHPBSHUPXcGVHPSHUPFLGRVHUHOVXSHUXVXDULR
,3&B50,' %RUUDHOFRQMXQWRGHVHP£IRURVGHOVLVWHPDHOERUUDGRHVLQPHGLDWR&XDOTXLHUSURFHVRTXHHVW«XVDQGRHO
VHPIRURUHFLEHXQHUURU(,'50FXDQGRLQWHQWHUHDOL]DUODVLJXLHQWHRSHUDFLµQVREUHHOFRQMXQWRGHVHPIRURV
3DUDTXHVHSXHGDUHDOL]DUHVWDRSHUDFLµQHOLGHQWLILFDGRUGHOSURFHVRGHEHFRLQFLGLUFRQVHPBSHUPXLG
VHPBSHUPGGRVHUHOVXSHUXVXDULR
*(79$/ 5HJUHVDHOYDORUGHVHPYDOSDUDHOVHPIRURHVSHFLILFDGRSRUVHPQXP
6(79$/ 'HILQHHOYDORUGHVHPYDOSDUDHOVHPIRURLQGLFDGRSRUVHPQXP(OYDORUHVHVSHFLILFDGRHQDUJYDO
*(73,' 5HJUHVHHYDORUGHVHPSLGSDUDHOVHPIRURHVSHFLILFDGRSRUVHPQXP
*(71&17 5HJUHVDHOYDORUGHVHPQFQWSDUDHOVHPIRURHVSHFLILFDGRSRUVHPQXP
*(7=&17 5HJUHVDHOYDORUGHVHP]FQWSDUDHOVHPIRURHVSHFLILFDGRSRUVHPQXP
*(7$// /HHWRGRVORVYDORUHVGHORVVHPIRURVHQHOFRQMXQWR\ORVDOPDFHQDHQHODUUHJORDSXQWDGRSRUDUJDUUD\
6(7$// 'HILQHWRGRVORVYDORUHVGHORVVHPIRURVHQHOFRQMXQWRWRPDQGRORVYDORUHVDSXQWDGRVSRUDUJDUUD\
7DEOD$2SFLRQHVGHFPGHQHOFRPDQGRVHPFWO.
semop La operación semop realiza en forma atómica un arreglo de operaciones sobre un conjunto de
semáforos, la sintaxis de esta operación es:
int semop(int semid, struct sembuf semoparray[], size_t nops);

El argumento semoparray es un apuntador a un arreglo de operaciones de semáforos. La estructura
sembuf es:
struct sembuf {
ushort sem_num; /* # de miembro en el conjunto (O,..., nsems-1 */
short sem_op; /* Operación (negativo, cero o positivo */
short sem-flg; /* 1PC_NOWAIT, SEM_UNDO */
El argumento nops especifica el número de elementos y a su vez de operaciones en el arreglo.
Si el valor de sem-op es positivo esto equivale a una operación V. El valor de sem_op es
sumado al valor del semáforo. Si se especifico SEM_UNDO el valor de sem_op es restado del valor de
ajuste del proceso de dicho semáforo.

$&2081,&$&,1'(,17(5352&(626 173
Si el valor de sem_op es negativo esto equivale a una operación P. Si el valor del semáforo es
MAYOR O IGUAL al valor absoluto de sem_op, el valor absoluto de sem_op es restado del valor del
semáforo. Esto garantiza que el valor resultante de el semáforo es mayor o igual a cero. Si la bandera
SEM_UNDO es especificada el valor absoluto de sem_op es sumado al valor de ajuste del proceso de
dicho semáforo. SÍ el valor de sem_op es negativo pero el valor del semáforo es menor que el valor
absoluto de sem_op puede ocurrir lo siguiente:
Si se especifico IPC_NOWAIT se regresa inmediatamente indicando el error EAGAIN.
Si no se especifico IPC_NOWAIT, e] valor de semncnt es incrementado y el proceso es
bloqueado hasta que pase algo de los siguiente:
El valor del semáforo llegue ha ser mayor o igual al valor absoluto de sem_op
(ocasionado por que otro(s) proceso(s) realizo operaciones semop con valores positivos). En
este momento el valor de semncnt es decrementado, el valor absoluto de sem_op es restado del
valor del semáforo. Si se especifico SEM-UNDO el valor absoluto de sem_op es sumado al
valor de ajuste del proceso respecto a ese semáforo.
El semáforo sea borrado del sistema con lo que se regresa el error ERMID
Se reciba una señal, con lo cuál se decrementará el valor de semncnt y se regresa el error
EINTR.
Si sem_op es cero indica que se desea esperar hasta que el valor del semáforo
sea cero. Si el valor del semáforo es cero se regresa inmediatamente. Si el valor del semáforo no
es cero puede ocurrir lo siguiente:
- Si se especifico IPC_NOWAIT, se regresa inmediatamente indicando el

error EAGAIN.
- Si no se especifico IPC_NOWAIT, se incrementa el valor de semzcnt y
se suspende el proceso hasta que ocurra algo de lo siguiente:
El valor del semáforo sea igual a cero. Entonces semzcnt es decrementado.

El semáforo sea borrado del sistema, regresando el error ERMID.
Se recibe una señal, decrementandose el valor de semzcnt regresando el error
EINTR.
NOTA: La atomicidad de la operación semop implica que se realizan todas las operaciones
indicadas o no se realiza ninguna.
El valor de ajuste tiene su aplicación cuando un proceso termina (exit) sin liberar el semáforo,
de forma tal que se aplica el valor de ajuste(es decir que se forza la realización
de operaciones V pendientes).
Una alternativa para el uso de los semáforos para manejo de exclusión mutua es el manejar el
bloqueo de registros (record locking), pero los semáforos son más rápidos que el bloqueo de los
registros.

APÉNDICE B
Java
B.l. Introducción
Este apéndice contiene un resumen general de Java con puntos básicos del lenguaje, que
facilitará el aprendizaje a aquellas personas que desean aprender o que están iniciado el camino hacia el
creciente mundo de Java.
Desde su lanzamiento en 1995, la plataforma Java ha sido la tecnología qué más ha sido
adoptada por la Industria en los últimos años. Desde un contexto mixto de Software y Hardware, la
tecnología Java puede ser concebida como un conjunto de atributos, que no son únicos de la tecnología,
pero la manera en como estos se combinan hace de Java una tecnología altamente recomendable para la
Industria y la computación dentro de las Empresas [74], véase la Figura B.1.
Desde otra perspectiva, Sun Microsystems define a Java como:
Un lenguaje simple, orientado a objetos, distribuido, interpretado, robusto, seguro, de
arquitectura neutral, portable, de alto desempeño, multi hilos y dinámico.
Un poco pretencioso de parte de Sun, aunque en realidad Java cumple con estas características.
x Orientado a Objectos: Java es un lenguaje orientado a objectos, ya que permite utilizar todas las
características de este paradigma, como clases, objectos, herencia, medularidad, reutilización de
código, etc.
x Interpretado: en lugar de generar código nativo de máquina, el compilador de Java genera byte-
code para la Máquina Virtual de Java (Java Virtual Machine).
x Portable y de Arquitectura Neutral: Los programas de Java son compilados a una arquitectura
nuetral en un formato de Byte-Code, por lo que una aplicación de Java puede ejecutarse sobre
cualquier sistema, siempre y cuando este tenga la Máquina Virtual de Java.
x Dinámico: Las clases pueden ser cargadas dinámicamente en tiempo
174

175 $31',&(%-$9$
0RGHORGH
6HJXULGDG
3RUWDELOLGDG $FFHVR
DO:HE
2EMHWRV-DYD 'HVDUUROOR
5£SLGR

7HFQRORJ¯D
-DYD

Figura B.1. Tecnología Java.

x Distribuido: Básicamente por la capacidad de Java de soportar operaciones sobre red de alto
nivel. Esta característica permite a Java bajar y ejecutar código atravez de Internet.
x Simple: Ya que es fácil de aprender, y además la semejanza con C , permite que los usuarios no
tengan muchos problemas para adaptarse a Java.
x Multi Hilos: Java soporta el manejo de múltiples hilos de ejecución que pueden manejar
diferentes tareas.
B.2. Historia
En el año de 1991 Sun Microsystems inició un proyecto corporativo de investigación

denominado "Green", el cual sin ser su objetivo principal se convirtió en el desarrollo de un lenguaje
similar a C y C+4-, que inicialmente fue bautizado como "Oak" por su creador. James Gosling. Java,
fue el nombre que algunos de los participantes en el proyecto acordaron asignarle al nuevo lenguaje,
tiempo después. Algunos meses después el proyecto Green sufrió dificultades, a tal grado que era
posible que Sun cancelara el proyecto, debido a que las circunstancias que originaron su creación
habían cambiado. De pronto en 1993 el Worid Wide Web incremento de forma importante su
popularidad, por lo que Sun vio nuevas oportunidades para Java, en el desarrollo de páginas Web con
contenido dinámico, esto por supuesto permitió que el proyecto continuara.
En 1995, Sun decidió lanzar su producto al mercado dentro de una Conferencia. Totalmente en
contra de sus expectativas el corporativo se encontró con un interés inmediato por parte del mercado,
en su mayor parte, debido a la fuerza que en ese entonces ya había adquiro el Worid Wide Web a nivel
mundial. Java entonces se convirtió en el lenguaje, que a diferencia de otros no surgió como lenguaje
académico o como el lenguaje desarrollado por un grupo pequeño de personas para su uso personal,
sino fue creado como consecuencia

%',)(5(1&,$6(175(-$9$<& 176
del desarrollo de otra tecnología emergente de Internet, enfocada a la parte comercial y de negocios, el
Worid Wide Web. [75].
B.3. Diferencias entre Java y C
La semejanza entre Java y C es muy grande, lo cual facilita mas el aprendizaje de Java para un
programador de C. Aun así existen algunas diferencias importantes de mencionar.
B.3.1. Estructura del programa
Un programa en Java esta formado por una o mas clases, cada una de las cuales es compilada a
byte-code, archivo de tipo .class el cual es ejecutable para la Máquina Virtual de Java. Por lo menos
alguna de estás clases debe definir el método main () dentro de ella, convirtiéndose en la clase principal
que inicia el programa.
Todo programa o aplicación de Java debe tener una función main O construida de la siguiente
manera:
public static void main(String args)
x public: define que el método main puede ser llamado por cualquier objeto.
x static: indica que el método main es una método de la clase.
x void: muy semejante en C, indica que el método main no regresa ningún valor.
Para ejecutar un programa, primero se debe generar el byte-code, para después ejecutar el
interprete Java seguido del nombre de la clase que contiene la función main (), omitiendo la extensión
.class. Por otro lado se encuentran los applets de Java, que es importante mencionar no son
aplicaciones, que puedan ser ejecutadas de la forma mencionada anteriormente. Un applet es una clase
de Java que puede ser ejecutada por otra aplicación de Java, Navegador de Internet o con el
visualizador de applets. [76].
B.3.2. Argumentos
El único argumento que el método main () recibe es un arreglo de cadenas de caracteres, en

donde la cantidad total de argumentos esta dada por el tamaño del arreglo (args.length). Para Java el
primer argumento es aquel que aparezca en la línea de comando después del nombre de la clase, y asi
sucesivamente separados por un espacio en blanco.
B.3.3. Valores de salida en un programa
Debido a que el método mainO en Java debe ser declarado como void, un programa en Java no
podrá regresar valores de salida con un retum al final del método main, por lo que el programador
deberá invocar el método System. exit ().
B.3.4. Estatuto import
El estatuto import es utilizado en Java para hacer accesibles los paquetes de clases que trae por
omisión, además de facilitar la escritura del código. Muy similar al include

177 $31',&(%-$9$
utilizado en C. Es importante mencionar que los estatutos import deben aparecer en el tope del código y
antes de cualquier declaración de la primera clase o interface. Existen dos formas de utilizarlo:
x En primera hacer accesible una clase de un paquete en especial, para que en vez de escribir j
ava. útil. Vector cada vez que se desee utilizar la clase, agregando import java. útil. Vector, solo
se tendrá que hacer referencia a la clase como Vector.
x Hace accesible todas las clases de un paquete, para no tener que definirlas una por una, por
ejemplo import. awt. *.
B.3.5. Caracteres para comentarios
Java define dos tipos de caracteres para comentarios:

Una sola linea: //
Múltiples lineas; empieza con /* para la primera linea y termina con */
B.3.6. Constantes
Para definir una constante en Java esta debe ser declarada como f inal y su valor debe ser
asignado al momento de que se defina la variable. #de£ine es el equivalente en C para definir
constantes de tipo static final en Java. Por ejemplo static final int KM = 1000;
B.3.7. Tipos de datos
A diferencia de C, Java define tamaños estrictos para los tipos de datos. En C un tipo de dato int
puede ser de 16, 32 o 64 bits, y un char puede ser con signo o sin signo. A menudo las variables en C
tienen basura dentro de su valor, Java tiene la característica de definir valores por omisión en la
inicialización.
7LSR &RQWHQLGR 9DORUSRU 7DPD³R

L Lµ
VKRUW HQWHURFRQVLJQR ELWV
LQW HQWHURFRQVLJQR ELWV
ORQJ HQWHURFRQ VLJQR ELWV
IORDW ,(((SXQFRIORWDQWH ELWV
GRXEOH ,(((SXQWRIORWDQWH ELWV
ERROHDQ WUXHRIDOVH IDOVH ELW
FKDU FDU£FWHUGH8QLFRGH ?X ELWV
E\WH HQWHURFRQVLJQR ELWV

7DEOD%,7LSRVGHGDWRVHQ-DYD
B.3.8. Colección de basura
Para los programadores de C este terminó puede sonar algo fuera de lo común, debido a que
están acostumbrados a preocuparse por crear objetos, para después liberar la memoria

%352*5$0$&,1(1-$9$178
que estos ocupaban. En Java se usa la técnica de colección de basura para detectar objectos que no
están mas en uso y liberarlos. Es por eso que no existe algo equivalente al comando free O de C, la
técnica de collección de basura se encarga de ese trabajo. Para la creación de objectos en Java se utiliza
la palabra reservada new, equivalente a raalloc () de C.
B.3.9. Apuntadores
Los apuntadores no existen en Java, por lo que la manipulación de punteros y direcciones de

memoria no esta permitida, ya que la referenciación a objetos como asignación de variables, elementos
de arreglos o argumentos pasados a métodos, es manejada automáticamente mediante referencias
implícitas.
B.3.10. Strings
Los Strings en Java no son cadenas de caracteres terminados con un cracter nulo ('\0') como en C, por
lo que Java casi lo define como tipo de dato primitivo, pero en realidad son instancias de la clase java.
lang. String. Una característica curiosa de los Strings, es que no se pueden realizar operaciones de
modificación sobre ellos, por lo que se tiene que hacer uso de la clase StringBuffer para hacerlo, y
después regresarlo a tipo String.
B.3.11. Arreglos
En Java el límite de un arreglo es delimitado de forma muy estricta, debido a esta característica
cualquier intento de leer mas allá del tamaño del arreglo, resulta en un error de compilación o en
tiempo de ejecución. Por esta razón para hacer referencia a un Arreglo en Java, se debe recurrir a
referenciación implícita, no a aritmética de puntos.
B.4. Programación en Java
Ya que Java es un lenguaje orientado a objetos, en esta sección hablaremos un poco del paradigma
orientado a objetos y de algunos conceptos básicos que es recomendable analizar antes de empezar a
programar.
La programación orientada a objetos no tiene una definición concreta, por lo que mencionaremos
conceptos, que le ayudaran a conceptualizar el paradigma orientado a objetos.
B.4.1. Objeto
Los objetos de software son modelados en base a los objetos reales, que como estos también
cuentan con estados (variables) y comportamientos (métodos). [77].

179 $31',&(%-$9$
B.4.2. Clase
En la vida diaria constantemente estamos en contacto con objetos del mismo tipo que
comparten características similares. Una clase es un conjunto de datos y métodos que operan sobre los
datos y comparten características de un objeto en específico. [781].
En la Figura B.2 se muestra una clase, formada por variables y métodos de instancia.
0«WRGRV
9DULDEOHV
Figura B.2. Una clase.
En el contexto de la programación orientada a objetos, podemos decir que un Objeto Alumno en

particular es una instancia de la clase de objetos denominado Alumno, sin embargo el estado
(variables) es independiente y puede variar con respecto a otros alumnos. Los Alumnos poseen estados
o variables (responsabilidad, participación, calificación, etc...) y comportamientos o métodos (hacer
tarea, estudiar, etc.) en común. Aplicando lo anterior, se puede crear una clase alumno que contiene
diferentes variables de instancia que contienen la responsabilidad, calificación, etc., de cada objeto
Alumno. Por otro lado la clase declara e implementa métodos de instancia que permiten al alumno
estudiar, asistir a grupos de discusión, etc., véase la Figura B.3.
*UXSRV
+DFHU
GH'LVFXVLµQ
7DUHDV
&DOLILFDFLµQ
3DUWLFLSDFLµQ
5HVSRQVDELOLGDG
$VLVWLUD
(VWXGLDU &ODVHV
Figura B.3. Clase alumno.
B.4.3. Método
Empleado en la programación orientada a objetos como la implementación de Procedimiento y

Funciones utilizadas en el lenguaje C.
B.4.4. Instancia
Considerando que la clase es una representación abstracta y general de un objeto, una instancia
es la representación concreta de la clase, véase Figura B.4.

%$3/,&$&,21(6<$33/(76180
&¯UFXOR
&ODVH &¯UFXOR
&¯UFXOR
$EVWUDFWR &¯UFXOR
&RQFUHWR

)LJXUD%,QVWDQFLDVGHXQDFODVH
&ODVH$
&ODVH% &ODVH(
&ODVH& &ODVH' &ODVH)
)LJXUD%-HUDUTX¯DGHFODVHV
B.4.5. Herencia
Es un término muy importante dentro de la programación orientada a objetos, se encarga de

organizar las clases de manera jerárquica con reglas muy estrictas, esto permite a la clase inferior
(subclase) heredar todos los métodos y variables de la clase padre (superclase).
En la Figura B.5 se muestra un ejemplo de la jerarquía de clases, en donde:
xLas clases C y D, son subclases de B.

xLa clase B es superclase de C y D.
xLa clase B es subclase de A.
xLa clase A es superclase de B y E.
B.5. Aplicaciones y Applets
Existen dos tipos de programas en Java:
Applet: Es un programa Java que se ejecuta por medio de un Visualizador Web en la máquina
del cliente. A diferencia de un apliación el applet depende de un Visualizador
181 $31',&(%-$9$
Web que soporte Java para su ejecución. Todo applet debe de implementar por lo uno y mas de
los métodos: init, start y paint.
Aplicaciones: Es un programa Java independiente, esto quiere decir que no necesita de un

Visualizador Web para ejecutarse. Se pueden crear toda clase de aplicaciones posibles, como si se
estuviera programando en un lenguaje convencional como C, Pascal, Visula Basic, etc. Curiosamente
el Navegador HotJava de Sun es una aplicación de Java. Cualquier aplicación de Java debe de
implementar por lo menos el método main.
B.5.1. Cómo crear o editar un programa
Como para muchos de los lenguajes existentes, un programa Java puede ser creado o editado
con un editor de texto sencillo que guarde los archivos en ASCII y sin caracteres de formato. Es
importante mencionar que el compilador de Java por convención acepta archivos con extensión .java,
por lo que cualquier programa que cree debe tener esta extensión.
Windows: NotePad o Edit de MS-DOS.
Unix: pico, vi o asedit.
B.5.2. Cómo compilar un programa
Ya sea que se trate de una aplicación o de un applet, o si se encuentra en Windows o Unix, para
compilar un programa Java, solo debe estar en el subdirectorio donde se encuentra el programa Java y
teclear lo siguiente:
javac {nombre del programa}
Por Ejemplo:
javac ProgramaJava.java
Después de compilar un programa Java sin errores el resultado es un archivo. class dentro del
mismo subdirectorio que el código fuente. Lo que contiene la clase es un bytecode de Java, que es un
código de plataforma independiente, para ser interpretado por la Máquina Virtual de Java.
B.5.3. Cómo ejecutar una aplicación
Tanto para la plataforma Windows o Unix, es el mismo comando. Una vez que ya se creo el
programa Java, se debe teclear lo siguiente:
java [nombre de la clase}
Por ejemplo:
java ProgramaJava
El argumento para el interprete de Java es el nombre de la clase que se desea ejecutar, no el
nombre del archivo, es decir que se debe de omitir la extensión. Es importante que escriba exactamente
el nombre de la clase, ya que el interprete de Java es sensible a mayúsculas / minúsculas.

%$3/,&$&,21(6<$33/(76182
B.5.4. Como ejecutar un Applet
Para ejecutar un applet, debe compilar primero el programa Java, para después cargar el archivo HTML
(página Web) que hace referencia al applet, dentro de un Visualizador Web que soporte applets de
Java, este puede ser Netscape, Explorer o Hotlava. Para esto debe indicar al Visualizador la ruta y
nombre completo donde creo el archivo HTML.
Existe la posibilidad de ejecutar un applet por medio de una aplicación llamada appletviewer, que trae
incluida el JDK (Java Development Kit), y se debe teclear lo siguiente:
appletviewer (ruta y nombre del archivo html)
Por ejemplo:
appletviewer file;/ejeiaplos/AppletJava
B.5.5. Métodos básicos de un Applet
init; Inicializa el applet cuando se carga por primera vez. En este proceso se crean los objetos y
la configuración inicial de variables.
start: Ya inicializado un applet, el arranque e sel siguiente paso. Si un applet fue detenido, para
cambiarse a otra página, cuando se regrese al applet, este arranca de nuevo. Este proceso se puede
repetir varias veces durante el ciclo de vida de un applet, a diferencia de la inicialización que solo
sucede una vez.
stop; La detención sucede principalmente cuando se abandona la página donde se encuentra el applet,
en este momento se suspende la ejecución de los hilos, para después volverlos a arrancar cuando se
visualice el applet de nuevo.
destroy: Elimina y limpia todos los hilos de ejecución antes de que el applet sea liberado o de que el
Visualizador lo termine. Por lo general este método no es usado a menos que recursos que se hayan
utilizado necesiten ser liberados, pero es recomendable utilizarlo.
B.5.6. Ejemplo de una Aplicación
El ejemplo que se muestra a continuación es un ejemplo muy sencillo de una aplicación, que
tiene el propósito de mostrar algunos de los fundamentos de Java como:
x Instanciación de clases.
x Condicional if y switch.
x Ciclos for y while.
x Manejo de excepciones-
x Métodos
x Manejo de Argumentos.
ProgramaJava.java
El ejemplo recibe dos argumentos, el primero una cadena de caracteres (string) y el segundo un
número entero. Como resultado produce la impresión en pantalla de la cadena de caracteres, tantas
veces como el segundo argumento. Por ejemplo si se ejecuta el programa de la siguiente forma java
ProgramaJava Hola 3, deberá desplegar lo siguente:

183 $31',&(%-$9$
HOLA
HOLA
HOLA
Usted mandó imprimir el mensaje un número impar de veces.
1 import java.útil. Vector;
En este ejemplo sólo utilzaremos la clase Vector(), por lo que en vez de importar todo el paquete
completo, sólo elegimos la clase Vector().
2 public class Pro grama Java { Encabezado del programa, define el nombre de la clase.
3 static String mensaje;
4 static int veces;
Declaración de variables globales, en este caso son estáticas debido a que son referenciadas por
el método main() que también es estático.
5 public Programa Java () {
6 Vector mensajes = new Vector();
Inicialización e instanciación de una clase Vector.
7 for(int i=0; i < veces; i++) {
Sintaxis: for(inicializaci6n; condición; incremento o decremento).
8mensajes.addElement(mensaje.toUpperCase());
Agrega el texto en mayúsculas que se recibió como argumento al Vector, tantas veces lo defina
el segundo argumento.
9 }
10 Imprime("Usted mando imprimir el mensaje un numero"+EsPar(veces)+"de veces");
Manda llamar el método EsPar para calcular si es par o impar el segundo argumento.
11 while(veces > 0) {
Sintaxis: while(condición)
12 Imprime((String)mensajes.elementAt(veces-1));
Imprime uno por uno todos los elementos del Vector, ejecutando un cast de valores tipo Objeto
que regresa el Vector a String.
13 eces—;
Decrementa en uno la variable;
14 }
15 }
16 public static void main(String[] args) { Implementación del método main.
17 try {
Inicia el rango del programa en donde se cacharán excepciones.
18 if(args.length==2) {
Verifica si los argumentos que esta recibiendo la clase son 2.
19 mensaje = new String(args[0] );
Almacena el primer argumento dentro de una variable de tipo String.
20 veces = Integer.parselnt(args[l]);

%$3/,&$&,21(6<$33/(76184
Convierte el segundo argumento a un entero válido si el argumento no es un entero válido

genera una excepción.
21 ProgramaJava programaJava = new Programa Java();
Genera una nueva instancia de la clase ProgramaJava.
22 } else {
23 throw new Exception(“El numero de parámetros es incorrecto”);
SÍ el número de argumentos es diferente de 2, genera una excepción.
24 }
25 } catch (Exception e) {
Captura las excepciones generadas y las imprime en pantalla.
26 Imprime(e.toString());
27 }
28 }
29 public static void Imprime (String msg) { Método que recibe como argumento un String y lo
despliega en pantalla.
30 System.out. println(msg);
31 }
32 public String EsParCint num) {
Método que recibe como argumento un entero, para procesarlo y regresar un String.
33 Sring es = new String();
Genera una nueva instancia de la clase String.
34 int res = num%2;
Calcula el residuo del argumento recibido.
35 switch(res) {
Asigna el valor a la variable res dependiendo el valor del residuo.
36 case 0: es = "par";
37 break;
38 case 1: es = "impar";
39 break;
40 }
41 retum es;
42 }
43 }
Código fuente de programaJava.java
import java.útil.Vector;
public class ProgramaJava {
static String mensaje;
static int veces;
public PrograJiiaJava() {
Vector mensajes = new Vector();
for(int i=0; i < veces; i++) {

185$31',&(%-$9$
mensaj es. addElemeut (mensaj e. toUpperCase () ) ;

}
Imprime ("Usted mando imprimir el mensaje un numero" +EsPar(veces)+ "de
vecesn);
while(veces > 0) {
Imprime ( (Strin,g)meD.saj es. elementAt (veces-1) ) ;
Veces---;
}
}
public static void main(String[] args) {
try {
if(args.length==2) {
mensaje - nev String(args[0]);
veces = Integer.parselnt(args[l3);
Pro grama Java programaJava = new ProgramaJavaO;
} else {
throv new Exception("El numero de parámetros es incorrecto");
}
} catch, (Exception. e) {
Imprime (e, toStringO) ;
}
}
public static void Imprime(String msg) {
System.out.println(msg);
}
public S-tring EsPar(int num) {
String es == nev String();
int res = num°/,2;
switcli(res) {
case 0: es = "par";
break;
case 1: es = "impar";
break;
}
return es;
}
}
B.5.7. Ejemplo de un Applet
El applet que se muestra a continuación, implementa dos áreas de texto, la primera editable y la
segunda no editable. Todo aquel texto que se escriba dentro de la primera área

%$3/,&$&,21(6<$33/(76186
de texto, se copiará a la segunda después de oprimir el botón Copiar, El botón Limpiar borra el
contenido de las dos áreas de texto.
Programa AppletJava.java
import j ava.applet.Applet;
import java.awt.*;
import java.awt.event.*;
public class AppletJava extends Applet {
Panel Panel_ditable;
Panel Panel_oEditable;
Panel Main;
Label Etiqueta_ditable;
Label Etiqueta_NoEditable;
TextArea Texto_Editable;
TextArea Texto_NoEditable;
Button Boton_Copiar;
Button Boton_Limpiar;
public void INIT()
Construye();
}
public void Construye() {
Etiqueta-Editable = new Label("EDITABLE",Label.CENTER);
Texto_Editable = new TextArea();
Panel_Editable = new Panel (new BorderLayout()) ;
Panel_Editable. add(Etiqueta_Editable ,BorderLayout. NORTH);
Panel_Editable. add (Texto_Editable, BorderLayout. CENTER);
Etiqueta_NoEditable = new Label("NO EDITABLE",Label.CENTER);
Texto_NoEditable = new TextArea() ;
Texto_NoEditable.setEditable(false);
Panel_NoEditable = new PaneKnew BorderLayout());
Panel_NoEditable. add(Etiqueta_NoEditable ,BorderLayout. NORTH);
Panel_NoEditable. add(Texto-NoEditable, BorderLayout. CENTER) ;
Main = new Panel(new GridLayout(2,D);
Main.add(Panel_Editable) ;
Main.add(Panel-NoEditable);
Boton_Copiar = new Button("Copiar");
Boton_Copiar.addActionListener(new ActionListener() {
public void actionPerformed(ActionEvent e){
Copia();
}
});
BotorL_Limpiar = new Button.(“Limpiar”) ;
Botón _Limpiar.addActionListener (new ActionListener () {

187$31',&(%-$9$
public void actionPerfornied(ActionEvent e) {

Limpia() ;
}
}) ;
th.is. setLayout (new BorderLayout () ) ;
this.add(Botoii--Linipiar, BorderLayout. NORTH);
this. add (Main,BorderLayout. CENTER) ;
this.add(Boton-Copiar,BorderLayout.SOUTH);
this. setSize (400,400) ;
}
public void Copia() {
Texto NoEditable.setText(“ ”);
Texto NoEditable. setText (Texto Editable.getText () ) ;
}
public void Limpia() {
Texto Editable. setText (“ ”);
Texto NoEditable.setText(“ ”);
}
}
B.5.7Archivo AppletJava.html
<HTML>
<HEAD>
<TITLE>AppletJava</TITLE>
</HEAD>
<BODY>
<APPLET CODE=”ApletJava” WIDTH=400 HEIGHT=400>
</APPLET>
</BODY>
</HTML>
B.6. Hilos
Que estudiante sentado en la mesa del comedor, en su vida no ha tenido el deseo de hacer los
problemas de Mecánica, leer el artículo de valores en México y América Latina, ver su serie de
televisión favorita y estudiar para su examen final de Ecuaciones Diferenciales, todo al mismo tiempo.
Por imposible que parezca, este tipo de situaciones suceden en el mundo real, tal vez menos
complicadas que la anterior o porqué no, aun mas difíciles. Un ejemplo claro, es la rutina común, que
realizamos al manejar, en donde se puede llegar a la situación de dar vuelta, cambiar de velocidad,
tener cuidado de no pegarle al carro que esta mal estacionado en la esquina y observar alrededor para
verificar que ningún despistado quiera cruzar la calle, todo al mismo tiempo. En el mundo de la
computación, a menudo

%+,/26188
las computadoras personales se enfrentan al mismo reto, de enviar un correo electrónico, imprimir un
documento, compilar un programa y bajar un programa de la Internet, al mismo tiempo. Después de tan
largo ejemplo, podemos inferir que la concurrencia es importante para nuestras vidas, a pesar de esto
muchos lenguajes de programación, no brindan la facilidad de implementar actividades concurrentes.
En este aspecto Java brinda al programador un conjunto de primitivas, donde puede especificar que sus
aplicaciones contengas hilos de ejecución (clase Thread), y la implementación de programación multi
hilos (multithreading), donde a cada hilo se le designa una parte del programa la cual es ejecutada
concurrentemente con otros hilos. La definición de un hilo entonces, puede ser una sección de código
ejecutado independientemente de otros hilos dentro de un mismo programa.
La clase Thread es un hilo de ejecución en un programa, en donde la máquina vitual de Java permite la
ejecución de hilos concurrentemente dentro de una aplicación. Cada hilo tiene una prioridad, en donde
los hilos con mayor prioridad son ejecutados preferentemente que aquellos con menor prioridad. En un
programa ejecutado por un hilo se crea una nueva instancia del objeto Thread, este hilo tiene
inicialmente la misma prioridad que aquel hilo que lo creo.
Cuando se ejecuta una aplicación, la maquina virtual crea un hilo que típicamente llama al método
main, de aqui en adelante la maquina virtual sigue ejecutando hilos hasta que:
x El método exit de la clase Runtime sea llamado.

x Todos los hilos hayan sido eliminados, ya sea por terminar de ejecutar el método run o
por la llamada al método stop.
B.6.1. Constructores
x public Thread(String NombreHilo) : que construye un hilo cuyo nombre es NombreHilo.
x public Thread() : construye un hilo cuyo nombre es "Thread"+n, donde n es un número entero,
por ejemplo Thread4,Thread5, etc.
El trabajo que un Thread debe realizar se encuentra definido dentro del método run, aunque
explícitamente no se hace una llamada a este método, cuando un programa inicializa la ejecución de un
hilo hace una llamada al método start, que a su vez hace la llamada el método run. [79]
El siguiente código crea un hilo y lo ejecuta.
Thread hilo = new Thread();

hilo.start()
B.6.2. Métodos
Los métodos que se mencionan a continuación no son todos los que posee la clase Thread, pero
si los mas importantes.
start

189$31',&(%-$9$
Inicializa la ejecución del hilo y la Máquina Virtual de Java llama al método run del hilo.
run
Si la construcción del hilo fue hecha usando un objeto ejecutable Runnable, entonces este método del
objeto Runnable es llamado; si este no es el caso, este método no hace nada.
seelp
Permite dormir al hilo, por una cantidad de milisegundos. La excepción que genera puede ser debido a
que otro hilo a interrumpido este hilo.
stop
Fuerza a un hilo a parar independientemente de lo que este ejecutando.
Interrupt
Interrumpe el hilo.
Isinterrupted
Verifica si el hilo ha sido interrumpido.
destroy
Destruye el hilo, sin desbloquear cualquiera de los monitores que este haya bloqueado.
IsAlive
Verifica si el hilo todavía esta vivo. Todo hilo se mantiene vivo mientras haya sido inicial izado y no
haya muerto.
suspend
Suspende el hilo. Si el hilo esta vivo suspende cualquier trabajo que este ejecutando hasta que sea
reiniciado.
resume
Reinicia un hilo suspendido. Si el hilo esta vivo pero suspendido, es reiniciado y permite que continué
su ejecución.
Yield
El hilo que esta siendo ejecutado es detenido temporalmente y permite a otros hilos ejecutarse.
B.6.3. Ejemplo de Threads
El ejemplo que se muestra a continuación es una aplicación que muestra la forma de como
implementar hilos. Cada uno de los 5 hilos en la aplicación imprime en pantalla su nombre, después de
dormirse un tiempo dado entre O y 3 segundos. [79]
Es importante mencionar que el ejemplo esta dividió en dos clases:
x ThreadJava: clase principal que instancia cinco clases ImprimeThread, e invoca el método
start de la clase Thread, en cada unos de los cinco objetos ImprimeThread para ponerlos listos
para ejecución.
x ImprimeThread: es una clase que es heredada de Thread, consiste de la variable de instancia
duérmete, un constructor y el método run. La variable duérmete, es inicializada con un entero
aleatorio entre O y 3000 cuando el objeto ImprimeThread

%+,/26190
es construido, para después dormirse el tiempo especificado por duérmete y después imprime en
pantalla su nombre.
La aplicación termina hasta que el último hilo ImprimeThread despierte e imprima su nombre.
public class ThreadJava {

public static void main(String[] args) {
ImprimeThread tl,t2,t3,t4,t5;
tí = new ImprimeThread();
t2 = new ImprimeThread();
t3 = new ImprimeThread()»
t4 = new ImprimeThread() ;
t5 = new ImprimeThread() ;
tl.start();
t2.start();
t3.start();
t4.start();
t5.start();
}
}
class Imprime Thread extends Thread {
int duérmete;
public ImprimeThread() {
duérmete = (int) (Math.random () *3000);
System.out.println(“Nombre:” +getName()+ “tiempo retraso: “
+ “duérmete”) ;
}
public void run() {
try {
Thread.sleep(duérmete);
} catch (InterruptedException e) {
System.out.printin(e.getMessage());
}
System.out.printInCgetName());
}
}

APÉNDICE C
Baci
C.l. Introducción
Baci es descendiente del lenguaje Pascal secuencial (PascaI-S) propuesto por Ben Ari. Pascal-S
es una extensión al lenguaje Pascal más algunas extensiones para soportar el manejo de concurrencia,
en particular se soporta la construcción cobegin ... coend para indicar ejecución concurrente y la
construcción wait... signal para controlar que ciertas partes de un programa sean ejecutadas de manera
mutuamente exclusiva. La diferencia entre la implementación de Pascal y Baci, es que Baci utiliza un
subconjunto del lenguaje C++ en lugar de Pascal.
Baci una herramienta sencilla de utilizar y fácil de entender, para usarlo se requiere solo
entender conceptos básicos de lenguajes de programación y conocer mecanismos de manejo de
concurrencia. En particular Baci soporta la creación de procesos, semáforos generales, semáforos
binarios y monitores.
Baci está compuesto de un compilador y de un interprete. El compilador toma como entrada un
programa escrito en un subconjunto del lenguaje C++ (llamado C- -) más algunas construcciones para
creación de procesos y manejo de concurrencia y produce como salida un programa en PCODE que es
un código para una máquina virtual. El interprete toma como entrada el programa en PCODE y lo
ejecuta directamente. El proceso de utilización de Baci se describe en la figura C.l.
C.2. El Lenguaje C- -
El lenguaje C- - son un subconjunto del lenguaje C++. Algunas restricciones y nuevos tipos que
se aplican en este compilador son ;
x Las operaciones de entrada y salida se manejan solamente con: cout, cin y end1.
x Solamente se soportan los tipos de datos int, char y string. Pero si soporta el manejo de arreglos
de estos tipos de datos.
191

192 $31',&(&%$&,
&RPSLODFLµQ
&UHDFLµQGH (MHFXFLµQGH
GHSURJUDPDV
SURJUDPDV SURJUDPDV
&RPSLODFLµQH[LWRVD
3&2'(SURJUDPDSFR
3URJUDPDFP EDFF EDLQWHUS
OLVWDGRSURJUDPDOVW
(GLWRU
GHWH[WR
(UURUHVGH
FRPSLODFLµQ
(MHFXFLµQQRDSURSLDGD
)LJXUD&,3URFHVRGHXWLOL]DFLµQGH%DFL
C.3. Creación de Procesos
La creación de procesos que se ejecutan concurrentemente se especifica a través de la

construcción cobegin. Esta instrucción engloba las instrucciones que se desean ejecutar de manera
concurrente. El interprete se encarga de ejecutar de intercalar aleatoriamente la ejecución de las
instrucciones contenidas en el cobegin. La ejecución después del bloque cobegin continúa hasta que
todos los procesos contenidos en él terminen. Un ejemplo del uso es:
cobegin{
proc1( ...); proc2(...);; procN(...);
}
C.4. Manejo de semáforos
El manejo de semáforos es soportado en Baci como un tipo predeclarado:
semaphore. Un semaphore es un valor no-negativo de una variable int que puede ser accesada
con algunas reestricciones. Los semáforos binarios(binarysem) , solo pueden tener los valores de O y
1. Las funciones de manejo de semáforos son:
x Creación que se logra al declarar variables tipo semaphore o binarysem.

C275$6,16758&&,21(6193
x initialsem ( semaphore, integer-expression ): permite inicializar un semáforo de cualquier

tipo.
x p(semaphore) o wait (semaphore): Si semaphore > O Entonces el semáforo se decrementa en 1
y se regresa a ejecutar la siguiente instrucción después de la llamada. Si semaphore == O,
Entonces el proceso no regresa a ejecutar su código y es bloqueado hasta que se desbloquee con
una llamada v o signal.
x v (semaphore) o signal (semaphore): Si semaphore = O y uno o más procesos están dormidos,
Entonces se despierta a un proceso de manera aleatoria.Si ningún proceso está esperando para
ser liberado por algún semáforo,Entonces el semáforo se incrementa en 1. En cualquier caso el
proceso que hizo la llamada continúa su ejecución.
C.5. Manejo de monitores

Baci soporta el concepto de monitor propuesto por Hoare con algunas reestricciones. Un monitor es un
bloque de código de C- - con algunas propiedades adicionales. Todas las funciones en las variables del
monitor son visibles para todos, pero las variables del monitor no son accesibles para todos los que
estén fuera del bloque y sólo pueden ser accesadas a través de las funciones del monitor.
En BACI, un monitor puede ser declarado sólo en un nivel global. Los monitores no pueden ser
jerarquizados. Sólo un procedimiento o función del monitor puede ser ejecutada a un tiempo. Esta
característica permite utilizar monitores para soportar la exclusión mutua.
Los monitores son soportados a través de: variables de condición, waitc que espera sobre una variable
de condición y signalc que señaliza una variable de condición. Las funciones de manejo de un monitor
son:
x Creación de una variable de condición, esto se realiza con el tipo de datos: condition. En un
sentido estricto una variable de tipo condition no tiene un valor. Realmente es como una
especie de cola de bloqueo dónde los procesos que realizan un llamado a la operación waitc son
bloqueados y los procesos que realicen un llamado a la operación sígnalc pueden desbloquear a
algún proceso esperando en la variable de condición.
x void waitc (condition cond, int prio): el proceso que manda llamar esta operación es
bloqueado en la variable de condición cond y se le asigna la prioridad prio para iniciar un re-
levantamiento.Esta acción a otros procesos del monitor ejecutarse.
x void waitc (conditíon cond): es similar a la anterior sólo que la prioridad es por omisión de 10.
x void sígnalc (condition cond): despierta a algún proceso bloqueado en la variable de condición
cond que tenga la mayor prioridad (la prioridad mayor es la que tenga el menor número de
prioridad).
x int empty (condition cond): regresa un 1 si no existe por lo menos un proceso bloqueado en la
variable de condición cond y O de otra manera.
C.6. Otras instrucciones
x SÍ una función es declarada como atomic, el intérprete no interrumpirá dicha función.

194 $31',&(&%$&,
x void suspend (void): Duerme al proceso que hizo el llamado.

x void revive (int process_id): Despierta al proceso identificado con process_id.
x init which_proc( void); Regresa el número de proceso actual.
x int random (int range): Regresa un entero seleccionado aleatoriamente entre O y range -
1.
C.7. Usando BACI
Un archivo fuente de Baci debe usar la extensión .cm . Para ejecutar un programa en BACI,
existen dos pasos a seguir :
a) Compilar el archivo “.cm” para obtener el archivo PCODE (.peo)
Usar: bacc [banderas-opcionales] nombre JirchivoFuente Banderas Opcionales:
x -h muestra la ayuda (Estas opciones).

x -c crea un archivo objeto (.pob)
b) Interpretar un archivo PCODE (.peo) para ejecutar el programa

Usar: bainterp [Banderas-opcionales] archivo_pcode
B anderasi -opcionales:
x -d entra al debugger, ejecuta paso a paso, muestra los breakpoints.

x -e muestra el registro activado (AR) sobre la entrada de cada proceso.
x -x muestra el AR sobre la salida de cada proceso.
x -t anuncia la terminacón de un proceso.
x -h muestra la ayuda (Estas opciones).
x -p muestra como son ejecutadas las instrucciones de PCODE
C.8 Ejemplo
El programa siguiente ilustra como se puede realizar la creación de procesos. Cada proceso
incrementa una variable global. Pruebe correr dicho programa varias veces y observe los diferentes
resultados.
incremen.cm
const int m == 5;
int n;
void incr (char id)
{ inti;
for (i = 1; i < = m; i = i + 1)
{
n=n+l;
cout <<id << “ n =”<<n << “ i =”;
cout << i << “ ” << id << endi;
}

C'21'(&216(*8,5%$&,195
}
main()
{
n=0;
cobegin
{
incr( 'A'); incr( 'B'); inc( 'C');
}-
cout<< “La suma es “ << n <<; endl;
}
C.9. ¿Dónde está siendo utilizado Baci?
Baci ha sido utilizado muchas veces en cursos de Introducción a Sistemas Operativos en la

Universidad de Alabama y en The College ofWilliam and Mary. También es utilizado en : Penn State
Harrisburg, Muhienberg College, St. Norbert College, Roberts Wesleyan College, Bostón University,
Lock Haven University, St. John's University, Colorado School of Mines, Xavier University of
Louisiana, The University of Texas at El Paso en Estados Unidos y en University ofDundee en Escosia,
University ofLuton en Inglaterra, Universidad de Oviedo en España, Australian Cathohc University en
Australia y ahora en ITESM (Instituto Tecnológico y de Estudios Superiores de Monterrey) en México.
C.10. Dónde conseguir Baci
Baci puede ser obtenido en http://cs.ua.edu/camp/baci

APÉNDICE D
JPNS
D.l. Introducción
Este es un pequeño manual que muestra las posibilidades que brinda el Simulador de Redes de
Petri (JPNS). El JPNS fue desarrollado en la universidad de Stuttgart por Thomas Braunl. JPNS soporta
la metodología de especificación y modelación a través de Redes de Petri., soporta la representación de
Plazas, Transiciones y Arcos y disparar la Red de Petri de manera paralela o secuencial. JPNS puede
ser obtenido en http://www.ee.uwa.edu.au/~braunl
D.2. Instalando JPNS.
Desempaque los archivos y agregúelos a un folder. Una vez hecha esta operación, el programa
se puede ejecutar, ya sea como applet o aplicación.
D.2.1. Como Applet:
Ejecutar el comando "appletviewerjpns.html" utilizando JDK, Asegúrese de tener todos los

archivos necesarios (html, java, class) en el path correcto para ejecutar la aplicación.
El sistema se puede correr en el Browser de su preferencia y también puede accesar a través de
Internet en http://www.ee.uwa.edu.au/braunl
Restricciones: Ejecutando el programa como un applet no es posible leer y escribir el disco
local. Además no se pueden salvar archivos. Esta es una restricción del browser.
D.2.2. Como aplicación:
Ejecuta el comando "java jpns" en el directorio en el cual haya instalado JPNS. Ejecutando el
programa como aplicación se tiene una completa funcionalidad del sw.
196

197 $31',&('M316
D.3. Los comandos del jPNS.
D.3.1. Menú FILE:

New: limpia el área de edición para iniciar un nuevo diseño.
Load: ejecuta el cuadro de diálogo para abrir un archivo de Red de Petri (*.net)
Save: Salva el diseño o dibujo actual. Si el diseño ya cuenta con un nombre, sólo se
sobreescribe el archivo.
Save As; abre un cuadro de diálogo para salvar el diseño actual en una archivo Jpns. Se hará
una pregunta antes de sobreescribir el archivo, en caso de que este ya existiera.
Quit: salir del jPNS.
D.3.2. Menú SETTINGS:
Las primeras dos opciones, las cuales son "Parallel" and "Sequentiell", especifican el modo que se
utilizará cuando se ejecute la red de petri sobre la cual se está trabajando. Se cuenta con las siguientes
opciones:
x Parallel Random: todas las transiciones disparan de manera paralela. Cuando hay dos
transiciones que están conectadas con el mismo nodo y este nodo sólo tiene un token, se activa
la opción ramdom, es decir, se ejecuta una transición activada aleatoriamente por el programa.
x Parallel Manual: se tiene la situación anterior , pero aquí el usuario decide que transición
activar.
x Sequentiell Random: las transiciones disparan una tras otra. Esta opción selecciona una
transición aleatoriamente para dispararla.
x SequentalH Manual: la misma situación de Sequentiell Random, pero aquí el usario tiene el
control de los disparos.
Las otras dos opciones de este menú son utilizadas para la salida gráfica. Si "Options" es
elegida, un cuadro de diálogo aparece, donde se puede seleccionar la opción "Show" , que pinta la
transición que se está disparando de la red de petri en ejecución y seleciona el retraso de tiempo entre
cada paso. La opción "Paintíng" le brinda al usuario la posibilidad de elegir una salida coloreada o en
blanco y negro (impresión).
D.4. Los iconos gráficos:
De izquierda a derecha, los iconos son:
ILJXUD',,FRQRGHODRSFLµQ5HO«DVH

'/26,&2126*5),&26198

)LJXUD',FRQRSDUD$GG1RGH
Reléase: A través de esta opción el usuario puede mover los componentes de la red de petri con
el botón izquierdo del mouse.
Add Node: El usuario puede colocar nodos con el botón izquierdo del mouse y con el derecho
mover los componentes de la red de petri.

)LJXUD',FRQRSDUD$GG7UDQVLWLRQ,
Add Transition: Agregar transiciones con el botón derecho del mouse.
)LJXUD',FRQRSDUD$GG(GJH

Add Edge: Para dibujar las ligas da un click con el botón izquierdo del mouse sobre el
componente de inicial de la liga y otro click sobre el componente correspondiente o componente final
de la liga. De otra manera la liga no podrá llevarse a cabo. Dando click's sobre la superficie del editor el
usuario podrá darle curvaturas a la liga
)LJXUD',FRQRSDUD$GG7RNHQ
Add Token: Haciendo click con el botón izquierdo del mouse agrega tokens a un nodo. Con el
botón derecho del mouse elimina tokens de un nodo.

199 $31',&('M316
)LJXUD',FRQRSDUDRSFLµQ(GLW
)LJXUD',FRQRSDUD2HOHWH
Edit; Haciendo click con el botón izquierdo del mouse abre el correspondiente cuadro de
diálogo de edición para el elemento seleccionado. Aquí el usuario puede introducir nombres,
condiciones, pesos, etc.
Delete: Con un click en el botón izquierdo del mouse elimina el componente seleccionado con
todas sus propiedades.

)LJXUD',FRQRSDUDRSFLµQVXDYH
Save: Misma funcionalidad que la opción save del menú File,
)LJXUD,FRQRSDUDODRSFLµQ0HPRUL]H
Memorize: Puede memorizar la red de petri con la que se está trabajando.

Draw Memorized: Puede trabajar con la red de petri memorizada.
Step: Ejecuta la red de petri en cuestión. Similar a un "run" en algún lenguaje de
programación.
Single Step : Ejecuta un paso de la red de petri en cuestión. Invoca al siguiente paso
cada vez que se le da un click a este botón.

'/26,&2126*5),&26200
)LJXUD',2,FRQRSDUDODRSFLµQ'UDZ0HPRUL]HG

)LJXUD',FRQRSDUDODRSFLµQ6WHS

)LJXUD',FRQRSDUDODRSFLµQ6LQJOH6WHS
La barra de status informa cuales son las acciones que se están ejecutando, el modo en el cual
se está ejecutando y un contador de pasos.
D.5. Ejemplo de red de petri en Jpns :
La exclusión mutua es una regla de sincronización la cual especifica que los accesos a variables
o recursos compartidos deben hacerse de uno a la vez cuando tenemos procesos concurrentes. Cuando
un proceso está ejecutando el código relativo al acceso de recursos o variables compartidas se dice que
está en su SECCIÓN CRITICA. La exclusión mutua puede ser implementada por medio de diferentes
mecanismos.
1. Dibuje una red de petri similar a la de la figura D.13.

2. Ajuste las siguientes propiedades.
2.1. Del menú Settings selecciones la opción Optíons y elija la opción Show.
2.2. Del menú Setting selecciones la opción Parallel y elija la opción Random.
2.3. Modifique las opciones anteriores y observe los resultados.
3. Ejecute paso a paso la red. Vea que sucede con las transiciones. La transición a la que
apuntan los tokens, transición potencialmente a disparar, se iluminará para indicar que ella
recibirá el disparo.
4. Ejecute de un solo paso la red.

201 $31',&('M316

3
0XWH[
6HFB 6HFB 3

, ,

)LJXUD'5HGGH3HWULSDUDPDQHMRGHH[FOXVLµQPXWXD
5. Agregue pesos a las diferentes ligas. Para hacerlo seleccione la opción "Editar" y haga
click con el botón izquierdo del mouse sobre alguna liga. Aumente el peso de la liga y
vea que se sucede. Ejecute el paso 3.
6. Guarde el ejemplo.
7. Construya los demás ejemplos, según las figuras dadas, y realice modificaciones para
ejecutarlas en modo paralelo y secuecial.

Referencias
[1] G. M. Amdahl and Blair G- A., Architecture of the IBM System/360, IBM Journal do Researche
and Development, 1964.
[2] C. J. Bashe, IBMs Early Computers, MIT Press, 1986.
[3] H. M. Deitel, An Introduction to Operating Systems, Addison-Wesley Publinshig Company,
1990.
[4] H. R. Grosch, The way it was in 1957, Datamation, 1977.
[5] S. P. Harbison and G. L. Steele, C: A reference manual, Prentice Hall, 1995.
[6] T. G. Lewis, “Where is Computing Heading?”, Computer, págs. 59-63, 1994.
[7] M. Maekawa and R. R. Oldefoeft, Operating Systems, Advanced concepts, Benjamin-
Cummings, 1987.
[8] E. Iacobucci, OS/2 Programmers guide, Me Graw Hill, 1988.
[9] D. Cameron and B. Rosenblatt, Learning GNUEmacs, OReilly and Associates, 1991.
[10] P. H. Enslow, “Multiprocessor Organizatíon-A survey”, Computing Surveys, págs-103-129,
1977.
[11] S. R. Boume, The UNIX System, Addison-Wesley, 1983.
[12] E. G. Coffman and T. A. Ryan, Operating Systems Theory, Prentice Hall, 1973.
[13] P. B. Hansen, Operating System Principies, Prentice Hall, 1973.
[14] A. S. Tanenbaum, Operating Systems, design and implementaüon, Prentice Hall, 1997.
[15] A. S. Tanenbaum, Modern Operating system, Prentice Hall, 1992.
[16] M. Milenkovic, Sistemas Operativos, Me Graw Hill, 1994.
[17] M. Bach, The design ofthe Unix Operating system, Prentice Hall, 1984.
[18] K. A. Robbins, Unix Programación Práctica, Prentice Hall, 1997.
[19] E. W. Dijkstra, Co-operating sequencial processes in programming languages, Academic
Press, 1968.
[20] L. Dowdy and C. Lowery, P.S. to Operating systems, Prentice Hall, 1993.
[21] S. Kleiman S. and D. Shah and B. Smaalders, Programming with Threads, Prentice Hall, 1999.
[22] E. Nemeth and S. Seebass and T. R. Hein, UNIX System Administration Handbook, Prentice
Hall, 1995.
[23] B. W. Kemighan, The C Programming Language, Prentice Hall, 1988.
[24] P. B. Hansen, The Architecture of Concurrent Programs, Prentice Hall, 1977.
[25] R. A. Finkel, An Operating Systems Vade Mecum, Prentice Hall, 1988.
202

5()(5(1&,$6203
[26] P. B. Hansen, “The Núcleos ofaMuItiprogramming System”, Communications of the ACM,

págs. 238-241, 1970.
[27] P. B. Hansen, “Structured Multiprogramming”, Communications of the ACM, págs. 574-578,
1972.
[28] E. W. Dijkstra, “Solution of a problem in concurrent programming control”, Communication of
the ACM, Pag. 569, 1965.
[29] F. Rueda, Sistemas Operativos, Me Graw Hill, 1979.
[30] W. R. Stevens, Unix networking programming, Prentice Hall, 1990.
[31] G. Held, Data Communications Networking Devices, John Wiley and Sons, 1989.
[32] S. A. Rago, UNIX System V Network Programming, Addison-Wesley, 1993.
[33] C. Bays, “A comparision of Next-Fit, First-Fit and Best-Fit”, Communications of the
ACAf,págs. 191-192,1977.
[34] L. Bic and A.C. Shaw, The Logical Design of Operating Systems, Prentice Hall, 1988.
[35] H. A. Habermann, “Syncronization of communicating processes”, Communications of the
ACM, págs. 171-176, 1972.
[36] B. W. Lampson, “A Scheduling Philosophy for Multiprocesing Systems”, Communications of
the ACM, págs. 347-369, 1968.
[37] W. A. Wulf, “Performance, monitors for multiprogramming systems”\Communication of the
ACM, págs. 780-790, 1971.
[38] G. Couloris and J. Dollimore and T. Kindberg, Distributed Systems: Concept and Design,
Addison-Wesley, 1994.
[39] W. Stallings, Operating Systems Internals and Design Principles, Prentice Hall, 1998.
[40] G. Brassard and P. Bratley, Algorithmics: Theory and Practice, Prentice Hall, 1988.
[41] A. J. Smith, “Cache Memories”, ACM computing surveys, págs. 433-530, 1982.
[42] R. L. Budzinski, “A Comparision of Dynamic and Static Virtual Memory Allocation
Algorithms”, IEEE Transactions on Software Engineering, págs. 122-131, 1981.
[43] L. Lamport, “Syncronization of Independent Process”,Acta informática, págs. 15-34,1976.
[44] F. J. Corbato, “Ah experimental time-sharing system”, Proceedings of the AFIPS fall joint
Computer Conference, págs. 335-344, 1962.
[45] G. A. Bowen and R. J. A. Buhr, The Logical Design of Multiple-Microprocessor Systems,
Prentice Hall, 1980.
[46] L. Lamport, “The mutual exclusión problem: a Theory of interprocess communications. Joumal
of the ACM, 313-326, 1986.
[47] L. Lamport, “The mutual exclusión problem: statement and solutions”, Joumal of the ACM,
327-360, 1986.
[48] J- E. Bums, “Mutual exclusión with linear waiting using binary shared variables”, SíGACT
News, págs. 42-A7, 1978.
[49] O. S. Carvalho and G. Roucairol, “On Mutual Exclusión in Computer Networks”,
Communications of the ACM, págs. 146-147, 1983.
[50] P. J. Courtois and et al, “Concurrent control with readers and writers”, Communications
oftheACM, págs. 667-668, 1971.
[51] M. Raynal, Algorithms for Mutual Exclusión, MIT Press,
1986.

5()(5(1&,$6204
[52] E B. Schneider, “Syncronization in distribuited programs”, Proceedings ofthe Sym-posium on

Principies of Distributed Computing, págs. 227-279, 1976.
[53] D. Curry, Using C on the unix System, 0’Reilly and Associates 1989.
[54] V. Kumar and A. Grama and A. Gupta and G. Karypis, Introduction to ParallelComputing:
Design andAnalysis of Algorithms, Benjamin-Cummings, 1994.
[55] A. S. Tanenbaum, Distributed Operating Systems, Prentice Hall, 1995.
[56] S. Patil, “Limitations and capabilities of Dijkstra’s semaphore primitives for coordination
among processes”, tech. rep. MIT, 1971.
[57] J. W. Havender, “Avoiding deadlock in multitasking system”, IBM Systems Joumal, págs. 74-
84, 1968.
[58] E. M. Gold, “Deadlock prediction: easy and difficult cases”, SIAM Journal of Computing,
págs. 320-336, 1978.
[59] R. Devillers, “Game interpretation ofthe deadlock avoidance problem”, Communications
oftheACM, págs. 741-745, 1977.
[60] R- O. Fontao, “A concurrent algorithm for avoiding deadlocks”, Proceedings of the ThirdACM
symposium on Operating Systems Principies, págs. 72-79, 1971.
[61] V. D. Gligor, “On deadlock detectíon in distributed systems”, IEEE transactions on Software
Engineering, págs. 435-440, 1980.
[62] A. N. Habermann, “Prevention of system deadlocks”, Communications ofthe ACM, págs. 373-
377, 1969.
[63] T. Kameda, “Testing deadlock fredoom of computer systems”, Joumal ofthe ACM, págs. 270-
280,1980.
[64] G. Newton, “Deadlock prevention, detection, and resolution: an annoted bibliographi”,
Operating Systems Review, págs. 33-44, 1979.
[65] A. Shoshani and E. G. Coffman, “Prevention, detection, and recovery from system deadlock”,
tech. rep. infonnation Science and Systems 1970.
[66] D. Zobel, “The deadlock problem: a clasifying bibliography”, Operating system review, págs.
6-16, 1983.
[67] http://chicago.eecs.uic.edu/~solworth/disk.html, “Disk Scheduling and Caching”,
[68] http://www.csc.vill.edu/~joyce/dsimlab/main.html, “An ínvestigation ofdisk scheduling
algorithms laboratory”.
[69] http://www.cs.strath.ac.uk/~af/OperatingSystemsl/6_diskscheduIing.htmI
“Diskarmscheduling”.
[70] L. Doug, Concurrent Programming in Java Design Principies and Pattems, Addison Wesley,
1997.
[71] S. Oaks and H. Wong, Java Threads, 0’Reilly, 1999.
[72] http://www.cis.unisa.edu.au/acrc/cs/dc/pma, “Process Migration for Amoeba”.
[73] http://bit.csc.Isu.edu/scs/SNOW/, “SNOW: A distributed dynamic system for meta-computing”.
[74] R. W. Atherton, “Moving JAVA to the Factory”, IEEE Spectrum, Vol. 35, págs. 18-23.
December, 1998.
[75] J. Byous, “Happy 3rd BirthDay”, tech. rep. Sun Microsystems Inc. 1998,
http://java.sun.com/features/1998/05/birthday.html.

5()(5(1&,$6205
[76] D. Flanagan, JAVA in a Nutshell, second ed. 0’Reilly 1997.

[77] L. Lemay and C. L. Perkins, Teach YourselfJAVA in 21 Days, Prentíce Hall, first ed.,1996.
[78] M. Campione and K. Wairath, The Java Tutorial. Object-Oriented Programming for the
Internet, Addison Wesley, first ed, 1996.
[79] H. M. Deitel and P. J. Deitel, JAVA How to Program, Prentíce Hall, second ed, 1998.

La publicación de esta obra la realizó
Editorial Trillas, S. A. de C. V.
División Administrativa, Av. Rio Churubusco 385,

Col. Pedro Mana Anaya, C.P. 03340, México, D. F.
Tel. 56 88 42 33, FAX 56 04 13 64
División Comercial, Calz. déla Viga 1132, C.P. 09439

México, D. F.. Tel. 56 33 09 95, FAX 56 33 08 70
Se terminó de imprimir el 13 de julio de 1999,

en los talleres de Impresos 2000, S. A. de C. V.
Se encuadernó en Terminados Gráficos Hidalgo.
CH BM2 80 TW

TORRES, Jose - Conceptos de Sistemas Operativos

Transféré par

Informations du document

Description originale:

Titre original

Copyright

Formats disponibles

Partager ce document

Partager ou intégrer le document

Options de partage

Avez-vous trouvé ce document utile ?

Ce contenu est-il inapproprié ?

Droits d'auteur :

Formats disponibles

TORRES, Jose - Conceptos de Sistemas Operativos

Transféré par

Droits d'auteur :

Formats disponibles

CONCEPTOS DE

Digitalización con propósito academico. Sistemas operativos

1. Conceptos Básicos. En este capítulo se presenta la evolución histórica de los

Digitalización con propósito academico. Sistemas operativos

7. Manejo de Interbloqueo. Se presentan diferentes algoritmos de manejo de

Con base en estos conocimientos el alumno podrá entender y evaluar el desempeño de

Digitalización con propósito academico. Sistemas operativos

1 Introducción a los sistemas operativos 15

2.13 Rutinas, corrutinas, procesos e hilos 26

Digitalización con propósito academico. Sistemas operativos

4.15.1 Estrategia Best Fit 45

Digitalización con propósito academico. Sistemas operativos

6.4 Problema de la actualización perdida 64

7.2.5 Algoritmo de Habermann 111

A.2 Manejo de archivos 138

Digitalización con propósito academico. Sistemas operativos

A.7.7 Manejo de teclado 157

Digitalización con propósito academico. Sistemas operativos

C.2 El lenguaje C— 195

Digitalización con propósito academico. Sistemas operativos

1.1. Conceptos de Sistemas Operativos

Se puede decir que un sistema operativo (SO) es el conjunto de programas que

Los recursos que maneja un SO son:

Digitalización con propósito academico. Sistemas operativos

1.1.1.Generaciones de Sistemas Operativos

40’s Generación 0. No existía un SO en las primeras computadoras. Los programas se

1.2.Hardware, Firmware y Software

El HW de un sistema computacional está compuesto principalmente de:

Digitalización con propósito academico. Sistemas operativos

7. Multiprogramación (Multitarea o Multitasking). La multiprogramación permite

El firmware se puede decir que es SW implementado en HW, surgió en 1951 con la

1.3.Evolución de la Programación Concurrente

Un programa concurrente es aquél que permite a una computadora hacer varias

1.3.1. (1955-1960) El reto de Hardware

1.3.2. (1960-1965) La crisis de Software

Digitalización con propósito academico. Sistemas operativos

OS360 (1966)—5000 hombres-año.

1.3.3. (1965-1970) Innovación Conceptual

• Surge la necesidad de dividir un programa concurrente en pequeños módulos

1.3.4. (1970-1975) Desarrollo de Lenguajes

• Se caracteriza por el desarrollo de una tecnología y notación precisa de los

Digitalización con propósito academico. Sistemas operativos

• El primer lenguaje es: “pascal concurrente” (1974) que soporta el concepto de

1.3.5. (1975- ) Entendimiento Formal

• Surge la idea de verificación de programas.

1.3.6. (1980- ) Refinamiento de Hardware

1.3.7. (1980-) Redes de Computadoras

• Ha tomado aproximadamente 20 años diseñar sistemas de cómputo confiables en

- Nuevo reto de HW.

Digitalización con propósito academico. Sistemas operativos

Para tener un mayor entendimiento de los temas vistos en este capítulo se

Digitalización con propósito academico. Sistemas operativos

Figura 2.1. Diagrama de los estados de un proceso.

2.4. Bloque de control de un proceso (PCB)

• Estado actual de un proceso.

2.5.Operaciones sobre procesos

• CREAR. Nombrar al proceso, insertarlo en la lista de procesos, determinar su

Digitalización con propósito academico. Sistemas operativos

• BLOQUEO. Quitarle el procesador esperando por la ocurrencia de un evento. Se

2.6. Creación jerárquica vs. creación no jerárquica

2.7. Procesamiento de interrupciones

2.8. Tipos de interrupciones