Sis Concur Distrib

Sistemas Concurrentes y Distribuidos.
Gu´ apuntes, problemas, seminarios y pr´cticas.
ıa,
a
Curso 2013-14

1

Contents
I

Gu´ de la asignatura
ıa

9

1 Gu´ de la asignatura
ıa
1.1

Datos generales . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11

1.4

Bibliograf´ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
ıa

1.2
1.3

II

11

Objetivos y temario . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12

Metodolog´ docente y evaluaciń . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
ıa
o

Apuntes de teor´
ıa

19

2 Tema 1. Introducciń.
o
2.1
2.2
2.3
2.4
2.5
2.6

21

Conceptos b´sicos y motivaciń . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
a
o

2.1.1

Conceptos b´sicos relacionados con la concurrencia . . . . . . . . . . . . . . . . . . . . . . 21
a

2.2.1

Consideraciones sobre el hardware . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22

2.1.2

Motivaciń de la Programaciń concurrente . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
o
o

Modelo abstracto y consideraciones sobre el hardware . . . . . . . . . . . . . . . . . . . . . . . . . 22

2.2.2

Modelo Abstracto de concurrencia . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25

Exclusiń mutua y sincronizaciń . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30
o
o

2.3.1
2.3.2

Concepto de exclusiń mutua . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
o

Condiciń de sincronizaciń . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32
o
o

Propiedades de los sistemas concurrentes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33

2.4.1
2.4.2

Correcciń de un sistema concurrente . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33
o
Propiedades de seguridad y vivacidad . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34

Verificaciń de programas concurrentes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35
o

2.5.1
2.5.2

Verificaciń de programas concurrentes. Introducciń . . . . . . . . . . . . . . . . . . . . . . 35
o
o

Enfoque axiom´tico para la verificaciń . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35
a
o

Problemas del tema 1. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36

3 Tema 2. Sincronizaciń en memoria compartida.
o
3.1

43

Introducciń a la sincronizaciń en memoria compartida. . . . . . . . . . . . . . . . . . . . . . . . . . 43
o
o
3

CONTENTS
3.2

3.3

3.1.1

Estructura de los procesos con Secciones Cr´
ıticas . . . . . . . . . . . . . . . . . . . . . . . . 44

3.2.1

Refinamiento sucesivo de Dijkstra . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47

3.1.2

3.5

3.2.2
3.2.3
3.2.4

Algoritmo de Dekker . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51
Algoritmo de Peterson . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52
Algoritmo de Peterson para n procesos. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54

Soluciones hardware con espera ocupada (cerrojos) para E.M. . . . . . . . . . . . . . . . . . . . . . 56

3.3.1

Introducciń . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56
o

3.3.4

Desventajas de los cerrojos. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59

3.3.2
3.3.5

La instrucciń LeerAsignar. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57
o
La instrucciń Intercambia. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58
o
Uso de los cerrojos. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60

Sem´foros para sincronizaciń . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60
a
o

3.4.1
3.4.2
3.4.3
3.4.4

Introducciń . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60
o

Estructura de un sem´foro . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61
a
Operaciones sobre los sem´foros. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61
a

Uso de los sem´foros . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62
a

Monitores como mecanismo de alto nivel . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63

3.5.1
3.5.2
3.5.3
3.5.4
3.5.5

3.6

Propiedades para exclusiń mutua . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45
o

Soluciones software con espera ocupada para E.M. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46

3.3.3
3.4

CONTENTS

3.5.6
3.5.7

Fundamento te´rico de los monitores . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63
o

Definiciń de monitor . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 64
o
Funcionamiento de los monitores . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67

Sincronizaciń en monitores . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 69
o
Semńtica de las seãles de los monitores . . . . . . . . . . . . . . . . . . . . . . . . . . . . 74
a
n

Implementaciń de monitores . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 78
o

Verificaciń de monitores . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 79
o


4 Tema 3. Sistemas basados en paso de mensajes.
4.1

4.2

93

Mecanismos b´sicos en sistemas basados en paso de mensajes . . . . . . . . . . . . . . . . . . . . 93
a

4.1.1

Introducciń . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 93
o

4.1.4

Espera selectiva . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 106

4.1.2
4.1.3

Vista logica arquitectura y modelo de ejecuciń . . . . . . . . . . . . . . . . . . . . . . . . . 94
o

Primitivas b´sicas de paso de mensajes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 95
a

Paradigmas de interacciń de procesos en programas distribuidos . . . . . . . . . . . . . . . . . . 111
o

4.2.1
4.2.2
4.2.3

Introducciń . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 111
o

Maestro-Esclavo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 111
Iteraciń s´
o ıncrona . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 113
4

CONTENTS
4.3

4.4

CONTENTS

4.2.4

Encauzamiento (pipelining) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 115

4.3.2

El paradigma Cliente-Servidor . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 117

Mecanismos de alto nivel en sistemas distribuidos . . . . . . . . . . . . . . . . . . . . . . . . . . . . 116

4.3.1
4.3.3
4.3.4

Introducciń . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 116
o
Llamada a Procedimiento (RPC) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 118
Java Remote Method Invocation (RMI) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 120


5 Tema 4. Introducciń a los sistemas de tiempo real.
o
5.1
5.2

III

Concepto de sistema de tiempo real. Medidas de tiempo y modelo de tareas. . . . . . . . . . . . 133

5.1.1
5.1.2
5.1.3

Definiciń, tipos y ejemplos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 133
o
Propiedades de los Sistemas de Tiempo Real . . . . . . . . . . . . . . . . . . . . . . . . . . 136

Modelo de Tareas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 138

Esquemas de planificaciń . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 142
o

5.2.1
5.2.2

Planificaciń C´
o ıclica. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 143
Planificaciń con prioridades . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 145
o

Seminarios y guiones de prćticas
a

6 Seminario 1. Programaciń multihebra y sincronizaciń con sem´foros.
o
o
a
6.1
6.2

6.4

7.2

151

Hebras POSIX . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 154

6.2.1

Introducciń . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 154
o

6.2.4

Par´metros e identificaciń de hebras . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 158
a
o

6.2.2
6.2.5

Creaciń y finalizaciń de hebras . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 155
o
o

Sincronizaciń mediante uniń . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 157
o
o
Ejemplo de hebras: c´lculo num´rico de integrales . . . . . . . . . . . . . . . . . . . . . . . 159
a
e

Introducciń a los Sem´foros . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 163
o
a
Sincronizaciń de hebras con sem´foros POSIX . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 165
o
a

6.4.1
6.4.2
6.4.3

Funciones b´sicas. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 165
a
Exclusiń mutua . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 167
o
Sincronizaciń . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 168
o

7 Prćtica 1. Sincronizaciń de hebras con sem´foros.
a
o
a
7.1

149

Concepto e Implementaciones de Hebras . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 151

6.2.3
6.3

133

171

Objetivos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 171

El problema del productor-consumidor . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 171
7.2.1
7.2.2

Descripciń del problema. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 171
o
Plantillas de c´digo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 172
o
5

CONTENTS
7.3

CONTENTS

7.2.3

Actividades y documentaciń . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 174
o

7.3.2

Plantillas de c´digo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 176
o

El problema de los fumadores. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 175

7.3.1
7.3.3

Descripciń del problema. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 175
o
Actividades y documentaciń. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 176
o

8 Seminario 2. Hebras en Java.
8.1
8.2
8.3
8.4
8.5
8.6

179

Hebras en Java . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 180

Creaciń de hebras en Java . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 180
o
Estados de una hebra Java . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 182
Prioridades y planificaciń. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 184
o

8.4.1

Un ejemplo m´s completo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 184
a

8.5.2

Ejemplo: C´lculo de m´ltiplos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 187
a
u

Interacciń entre hebras Java. Objetos compartidos . . . . . . . . . . . . . . . . . . . . . . . . . . . . 186
o

8.5.1

Implementando exclusiń mutua en Java. C´digo y m´todos sincronizados. . . . . . . . . 186
o
o
e

Compilando y ejecutando programas Java . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 189

9 Prćtica 2. Programaciń de monitores con hebras Java.
a
o
9.1
9.2
9.3

9.4
9.5
9.6

191

Objetivos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 191
Implementaciń de monitores nativos de Java . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 191
o

9.2.1
9.2.2

Monitores como Clases en Java . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 191
M´todos de espera y notificaciń. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 192
e
o

Implementaciń en Java de monitores estilo Hoare . . . . . . . . . . . . . . . . . . . . . . . . . . . . 195
o

Productor-Consumidor con buffer limitado . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 198

El problema de los fumadores . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 199
El problema del barbero durmiente. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 200

10 Seminario 3. Introducciń al paso de mensajes con MPI.
o

203

10.1 Message Passing Interface (MPI) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 204
10.2 Compilaciń y ejecuciń de programas MPI . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 205
o
o

10.3 Funciones MPI b´sicas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 205
a

10.3.1 Introducciń a los comunicadores . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 206
o
10.3.2 Funciones b´sicas de env´ y recepciń de mensajes . . . . . . . . . . . . . . . . . . . . . . 208
a
ıo
o

10.4 Paso de mensajes s´
ıncrono en MPI . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 209
10.5 Comunicaciń no bloqueante . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 210
o

11 Prćtica 3. Implementaciń de algoritmos distribuidos con MPI.
a
o

215

11.1 Objetivos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 215
11.2 Productor-Consumidor con buffer acotado en MPI . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 215
6

CONTENTS

CONTENTS

11.2.1 Aproximaciń inicial en MPI . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 215
o
11.2.2 Soluciń con selecciń no determinista . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 217
o
o

11.3 Cena de los Fil´sofos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 218
o
11.3.1 Cena de los fil´sofos en MPI . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 218
o
11.3.2 Cena de los fil´sofos con camarero en MPI . . . . . . . . . . . . . . . . . . . . . . . . . . . . 221
o

7

Part I

ıa

9

Chapter 1

ıa
1.1

Datos generales

Datos generales de la asignatura.

nombre
titulaciń
o
tipo
curso y cuatrimestre
adscrita al departamento
cr´ditos totales
e
horas semanales presen.
horas sem. no presen.
m´s informaciń
a
o

Recursos en la Web

Sistemas Concurrentes y Distribuidos
Grado en Inform´tica
a
obligatoria (materia comń de la rama)
u
2o curso, 1er cuatrim.
Lenguajes y Sistemas Inform´ticos
a
6 ECTS
4 horas (2 teor´ + 2 prćticas)
ıa
a
4 horas
http://lsi.ugr.es/scd
https://tutor2.ugr.es
http://lsi.ugr.es/lsi/node/943

En la web se pueden encontrar los siguientes recursos relacionados con la asignatura:
• P´gina Web de la asignatura con documentaciń para alumnos:
a
o

◾ http://lsi.ugr.es/scd (para bajar la doc. se requiere login/passwd, usar login: alumno, password:
pc99scd)

• Sistema web para gestiń de grupos, notas y comunicaciń con alumnos (sistema Tutor)
o
o
◾ p´g. principal: https://tutor2.ugr.es
a
◾ ficha asignatura: https://tutor2.ugr.es/functions/index.php/idop 950/subject 100

• Sitio web del departamento:

◾ p´g. principal: http://lsi.ugr.es
a
◾ ficha de la asignatura: http://lsi.ugr.es/lsi/node/943
◾ profesorado depto.: http://lsi.ugr.es/lsi/personal
11

SCD (13-14). Gu´ de la asignatura.
ıa
Grupos grandes (teor´
ıa)

Gr
A
B
C
D

Grupos pequeõs (prćticas).
n
a

1.2

Gr
A1
A2
A3
B1
B2
B3
C1
C2
C3
D1
D2

D´
ıa
Viernes
Lunes
Jueves
Mi´rcoles
e
D´
ıa
Lunes
Martes
Jueves
Martes
Mi´rcoles
e
Viernes
Lunes
Lunes
Mi´rcoles
e
Martes
Mi´rcoles
e

Objetivos y temario

Horas
09:30-11:30
11:30-13:30
15:30-17:30
17:30-19:30
Hora
11:30-13:30
11:30-13:30
11:30-13:30
09:30-11:30
09:30-11:30
09:30-11:30
18:30-20:30
18:30-20:30
17:30-19:30
15:30-17:30
15:30-17:30

Profesor
Carlos Ureã Almagro
n
Jose M. Mantas Ruiz
Juan A. Holgado Terriza
Pedro Villar Castro
Profesor
Carlos Ureã
n
Carlos Ureã
n
Ana M. Sńchez
a
Pedro Villar
Jos´ Miguel Mantas
e
Ana M. Sńchez
a
Pedro Villar
Sandra S. Rodr´
ıguez
Sandra S. Rodr´
ıguez
Pedro Villar
M. del Mar Abad

Objetivos.

• Comprender la importancia de la programaciń concurrente en las aplicaciones de hoy en d´
o
ıa.

• Identificar las principales caracter´
ısticas de los distintos tipos de sistemas concurrentes que existen.

• Conocer y entender los problemas que plantea el desarrollo de programas concurrentes, y que no
aparecen en la programaciń secuencial.
o
• Entender los conceptos de sincronizaciń y exclusiń mutua entre procesos.
o
o

• Identificar las propiedades de seguridad y vivacidad que un sistema concurrente debe cumplir y ser
capaz de razonar si dichas propiedades se cumplen.
• Conocer los principales modelos de programaciń concurrente, paralela y distribuida.
o

• Adquirir experiencia y conocimiento en los mecanismos de sincronizaciń y comunicaciń que se utilizan
o
o
en la actualidad para desarrollar programas concurrentes tanto para sistemas de memoria compartida
como para sistemas distribuidos.

• Entender el funcionamiento de sem´foros y monitores como mecanismos de sincronizaciń para memoria
a
o
compartida y comprender c´mo se pueden resolver problemas de programaciń concurrente usando
o
o
monitores.

creado October 4, 2013- p´gina 12 / 222
a

ıa

• Ser capaz de desarrollar algoritmos para sistemas basados en memoria compartida y para sistemas
distribuidos que resuelvan problemas modelo en programaciń concurrente.
o
• Conocer y ser capaz de usar bibliotecas y plataformas estandarizadas para la implementaciń de
o
programas concurrentes basados en memoria compartida y para sistemas distribuidos
• Conocer las tćnicas m´s destacadas para el diseõ de sistemas de tiempo real
e
a
n

Temario de teor´
ıa

Se divide en los siguientes cap´
ıtulos:

1. Introducciń a la Programaciń Concurrente.
o
o

2. Algoritmos y mecanismos de sincronizaciń basados en memoria compartida.
o
3. Sistemas basados en paso de mensajes.

4. Introducciń a los sistemas de tiempo real.
o

Temario de prćticas
a
Prćticas evaluables:
a

1. Resoluciń de problemas de sincronizaciń con sem´foros.
o
o
a
2. Programaciń de monitores con hebras.
o

3. Programaciń de aplicaciones distribuidas.
o

4. Programaciń de tareas peri´dicas con prioridades.
o
o

Seminarios impartidos presencialmente en las clases de prćticas:
a

1. Introducciń a la programaciń mutihebra usando sem´foros.
o
o
a
2. Introducciń a la programaciń mutihebra con monitores.
o
o

3. Introducciń al uso de una interfaz de paso de mensajes.
o

1.3

Metodolog´ docente y evaluaciń
ıa
o

Metodolog´ docente.
ıa

Dado el carćter b´sico de la asignatura, se pretende que el alumno adquiera los conocimientos te´ricos
a
a
o
de la materia y los sepa aplicar con soltura. Para ello, las actividades de enseãnza-aprendizaje que se
n
realizarń serń una combinaciń de:
a
a
o
• Actividades presenciales, entre las que se incluyen:
◾ Clases magistrales

a

ıa

◾ Resoluciń de ejercicios/problemas individuales y/o en grupo
o
◾ Sesiones prćticas en laboratorio
a
◾ Tutor´
ıas

◾ Pruebas objetivas

• Actividades no presenciales, que pueden ser:
◾ Estudio individual o en grupo

◾ Realizaciń de ejercicios/problemas/trabajos tanto individuales como en grupo
o
◾ Confecciń de la carpeta de aprendizaje o portafolio de prćticas.
o
a

Evaluaciń
o

Un papel importante del proceso de aprendizaje, es la evaluaciń que tiene una doble misiń:
o
o
• Garantizar la adquisiciń de competencias
o

• Llevar a cabo una evaluaciń formativa en la que se fomenta la continua retroalimentaciń del alumno
o
o
que puede conocer en todo momento c´mo va en su aprendizaje. Para ello, en todo momento:
o
◾ Se resolverń las pruebas objetivas, ejercicios, problemas, etc.
a

◾ Se mantendr´ una carpeta de aprendizaje con todo el material generado en las prćticas de la
a
a
asignatura. Esta carpeta muestra el proceso de aprendizaje en prćticas: res´menes, ejercicios y
a
u
sus soluciones, dudas y sus respuestas, reflexiones, indagaciones y b´squeda bibliogr´fica, diario
u
a
de clase, resultados de reuniones de grupo o tutor´ etc. La carpeta ser´ revisada al menos una
ıas,
a
vez en tutor´
ıas.

Calificaciń
o

Los criterios b´sicos para obtener la calificaciń son los siguientes:
a
o

• La m´xima nota en teor´ y prćticas son 5 puntos en cada una.
a
ıa
a

• Para aprobar la asignatura es necesario tener una calificaciń num´rica superior o igual a 5 (sobre
o
e
10), sumando teor´ y prćticas.
ıa
a

• Adem´s del requisito anterior, se establece como requisito adicional para superar la asignatura que,
a
tanto la calificaciń correspondiente a la parte te´rica como la correspondiente a la parte prćtica,
o
o
a
sean cada una mayores o iguales a 2 (sobre 5).

Evaluaciń de teor´ y/o prćticas ya superadas
o
ıa
a
Existen estas opciones:

Para los alumnos que no logren aprobar la asignatura en la convocatoria ordinaria de febrero (o septiembre) del aõ 2014
n

Si el alumno obtiene una nota igual o superior a 2,5 en teor´ o prćticas, se podr´ guardar dicha nota
ıa
a
a
para la convocatoria de septiembre (o diciembre) del aõ 2014.
n

a

ıa

Para los alumnos que no logren aprobar la asignatura en el curso acad´mico 2013-14
e

Si el alumno obtiene una nota igual o superior a 2,5 en prćticas con evaluaciń continua, se podr´ guardar
a
o
a
dicha nota para todas las convocatorias del curso 2014-15.
Modalidades de evaluaciń
o

Los alumnos pueden seleccionar una de las siguientes dos modalidades de evaluaciń:
o

• Evaluaciń continuada y formativa: Basada en la asistencia regular a clases de teor´ y prćticas y
o
ıa
a
la realizaciń de las actividades propuestas.
o

• Examen final: Basada en la realizaciń de un examen escrito relativo al temario de teor´ y la defensa
o
ıa,
de las prćticas ante el profesor de prćticas asignado al alumno.
a
a

Evaluaciń continuada y formativa
o

En esta modalidad, los alumnos tienen que asistir a clase regularmente y realizar las pruebas y ejercicios
que se plantean a lo largo del curso.
• Deben asistir a todas las pruebas objetivas de teor´ o prćticas.
ıa
a

• Se admite que, de forma justificada, se falte a una prueba como m´ximo.
a

• Esta modalidad ser´ el mecanismo de evaluaciń por defecto de todos los alumnos salvo para los que
a
o
soliciten de forma justificada (y les sea concedida) la otra modalidad (evaluaciń unica final)
o ´

Calificaciń de teor´ en evaluaciń continua
o
ıa
o

La calificaciń de teor´ (5 puntos) se reparte de la siguiente forma:
o
ıa

• 4,5 puntos corresponden a 4 pruebas objetivas individuales realizadas al final de cada tema. La
distribuciń de la puntuaciń por temas es la dada en la siguiente tabla:
o
o
Tema
Punt. m´x.
a

1
0,7

2
1,8

3
1,6

4
0,4

Total
4,5

• 0,5 puntos correspondiente a la resoluciń de ejercicios, problemas, y/o trabajos.
o

Calificaciń de prćticas en evaluaciń continua
o
a
o

La calificaciń de prćticas (5 puntos) se obtiene de la siguiente forma:
o
a

• 4,5 puntos correspondientes a cinco pruebas objetivas (prćticas 1, 2, 3, 4 y 5) que se realizan durante
a
la ultima sesiń de prćticas de la parte a evaluar. Esta a su vez se distribuye como indica la siguiente
´
o
a
tabla:
Tema
Punt. m´x.
a

1
1,2

2
1,5

3
1,3

4
0,5

Total
4,5

• 0,5 puntos de las soluciones de los ejercicios propuestos que sean presentadas en clase a los compa˜eros
n
o enviadas al profesor.

La carpeta de aprendizaje podr´ ser revisada al menos una vez durante el cuatrimestre en tutor´
a
ıas

a

ıa
Evaluaciń por examen final
o

Para aquellos alumnos que hayan solicitado y les haya sido concedida la evaluaciń por esta modalidad.
o
Consta de dos partes:
• Examen de teor´ tendr´ lugar en la fecha fijada por el centro
ıa:
a

• Defensa de las prćticas: tendrń lugar en las fechas en las que se reserven para este fin las aulas
a
a
de prćticas de la ETSIIT
a

1.4

Bibliograf´
ıa

Bibliograf´ fundamental (1/2)
ıa

• G. R. Andrews. Foundations of Multithreaded, Parallel, and Distributed Programming. Addison
Wesley, 2000.
• M. Ben-Ari. Principles of Concurrent and Distributed Programming. Prentice Hall, 2nd edition. 2006.

• J. T. Palma, C. Garrido, F. Sńchez, A. Quesada. Programaciń Concurrente. Thomson-Paraninfo.
a
o
2003.
• G. R. Andrews. Concurrent Programming: Principles and Practice. Benjamin/Cummings, 1991.

• F. Almeida, D. Gimenez, J. M. Mantas, A.M. Vidal. Introducciń a la Programacion Paralela. Parano
info Cengage Learning, 2008.

Bibliograf´ fundamental (2/2)
ıa

• V. Kumar , A. Grama, A. Gupta, G. Karypis. Introduction to Parallel Computing. Benjamin/Cummings
Publishing Company, 2003.

• N. Santoro. Design and analysis of distributed algorithms. Wiley Series on parallel and distributed
computing. 2007.

• A. Burns, A. Wellings. Sistemas de Tiempo Real y Lenguajes de Programaciń. (3a ediciń). Addison
o
o
Wesley, 2003.
• G.F. Coulouris, J. Dollimore, T. Kindberg Distributed Systems: Concepts and Design (5a editciń).
o
Pearson, 2011.

Bibliograf´ complementaria.
ıa

• N. Gehani, A.D. McGettrick. Concurrent Programming. International Computer Science Series.
Addison-Wesley. 1988.
• C. Hughes, T. Hughes. Professional Multicore Programming: Design and Implementation for C++
Developers. Wrox Programmer to Programmer. 2008.

a

ıa

• C. Breshears. The Art of Concurrency: A Thread Monkey´ Guide to Writing Parallel Applications.
s
´
OReilly Media. 2009.

• N.A. Lynch. Distributed Algorithms. Morgan Kaufmann. 1996.

a

ıa

a

Part II

Apuntes de teor´
ıa

19

Chapter 2

Tema 1. Introducciń.
o
2.1

2.1.1

Conceptos b´sicos y motivaciń
a
o

Conceptos b´sicos relacionados con la concurrencia
a

Programa concurrente, concurrencia y programaciń concurrente
o

• Programa secuencial: Declaraciones de datos + Conjunto de instrucciones sobre dichos datos que
se deben ejecutar en secuencia.
• Programa concurrente:
l´gicamente en paralelo.
o

Conjunto de programas secuenciales ordinarios que se pueden ejecutar

• Proceso: Ejecuciń de un programa secuencial.
o

• Concurrencia: Describe el potencial para ejecuciń paralela, es decir, el solapamiento real o virtual
o
de varias actividades en el tiempo.

• Programaciń Concurrente (PC): Conjunto de notaciones y tćnicas de programaciń usadas para
o
e
o
expresar paralelismo potencial y resolver problemas de sincronizaciń y comunicaciń.
o
o
• La PC es independiente de la implementaciń del paralelismo. Es una abstracciń
o
o

Programaciń paralela, programaciń distribuida y programaciń de tiempo real
o
o
o

• Programaciń paralela:
o
Su principal objetivo es acelerar la resoluciń de problemas concretos
o
mediante el aprovechamiento de la capacidad de procesamiento en paralelo del hardware disponible.

• Programaciń distribuida: Su principal objetivo es hacer que varios componentes software localizados
o
en diferentes ordenadores trabajen juntos.

• Programaciń de tiempo real: Se centra en la programaciń de sistemas que estń funcionando
o
o
a
continuamente, recibiendo entradas y enviando salidas a/desde componentes hardware (sistemas reactivos), en los que se trabaja con restricciones muy estrictas en cuanto a la respuesta temporal (sistemas
de tiempo real).
21

SCD (13-14). Tema 1. Introducciń..
o

2.1.2

Motivaciń de la Programaciń concurrente
o
o

Beneficios de la Programaciń concurrente
o

La PC resulta m´s complicada que la programaciń secuencial.
a
o

¿ Por qu´ es necesario conocer la Programaciń Concurrente ?
e
o
1. Mejora de la eficiencia

La PC permite aprovechar mejor los recursos hardware existentes.
• En sistemas con un solo procesador:

◾ Al tener varias tareas, cuando la tarea que tiene el control del procesador necesita realizar una
E/S cede el control a otra, evitando la espera ociosa del procesador.
◾ Tambiń permite que varios usuarios usen el sistema de forma interactiva (actuales sistemas
e
operativos multisusuario).

• En sistemas con varios procesadores:

◾ Es posible repartir las tareas entre los procesadores, reduciendo el tiempo de ejecuciń.
o
◾ Fundamental para acelerar complejos c´mputos num´ricos.
o
e

Beneficios de la Programaciń concurrente (2)
o

2. Mejora de la calidad

Muchos programas se entienden mejor en t´rminos de varios procesos secuenciales ejecutńdose concure
a
rentemente que como un unico programa secuencial.
´
Ejemplos:

• Servidor web para reserva de vuelos: Es m´s natural, considerar cada peticiń de usuario como
a
o
un proceso e implementar pol´
ıticas para evitar situaciones conflictivas (permitir superar el l´
ımite de
reservas en un vuelo).
• Simulador del comportamiento de una gasolinera: Es m´s sencillo considerar los surtidores, clientes,
a
veh´
ıculos y empleados como procesos que cambian de estado al participar en diversas actividades
comunes, que considerarlos como entidades dentro de un unico programa secuencial.
´

2.2

2.2.1

Modelo abstracto y consideraciones sobre el hardware
Consideraciones sobre el hardware

Modelos de arquitecturas para programaciń concurrente
o

a

o

Mecanismos de implementaciń de la concurrencia
o
• Dependen fuertemente de la arquitectura.

• Consideran una m´quina virtual que representa un sistema (multiprocesador o sistema distribuido),
a
proporcionando base homogńea para ejecuciń de los procesos concurrentes.
e
o
• El tipo de paralelismo afecta a la eficiencia pero no a la correcciń.
o

Concurrencia en sistemas monoprocesador

• Multiprogramaciń: El sistema operativo gestiona c´mo m´ltiples procesos se reparten los ciclos de
o
o
u
CPU.
• Mejor aprovechamiento CPU.

• Servicio interactivo a varios usuarios.

• Permite usar soluciones de diseõ concurrentes.
n

• Sincronizaciń y comunicaciń mediante variables compartidas.
o
o

a

o

Concurrencia en multiprocesadores de memoria compartida

• Los procesadores pueden compartir o no f´
ısicamente la misma memoria, pero comparten un espacio de
direcciones compartido.
• La interacciń entre los procesos se puede implementar mediante variables alojadas en direccciones
o
del espacio compartido (variables compartidas).
• Ejemplo: PCs con procesadores muticore.

Concurrencia en sistemas distribuidos

• No existe un memoria comń: cada procesador tiene su espacio de direcciones privado.
u

• Los procesadores interaccionan transfirińdose datos a trav´s de una red de interconexiń (paso de
e
e
o
mensajes).
• Programaciń distribuida: adem´s de la concurrencia, trata con otros problemas como el tratamiento
o
a
de los fallos, transparencia, heterogeneidad, etc.
• Ejemplos: Clusters de ordenadores, internet, intranet.

a

o

2.2.2

Modelo Abstracto de concurrencia

Sentencias at´micas y no at´micas
o
o
Sentencia at´mica (indivisible)
o

Una sentencia o instrucciń de un proceso en un programa concurrente es at´mica si siempre se ejecuta de
o
o
principio a fin sin verse afectada (durante su ejecuciń) por otras sentencias en ejecuciń de otros procesos
o
o
del programa.
• No se ver´ afectada cuando el funcionamiento de dicha instrucciń no dependa nunca de como se
a
o
estń ejecutando otras instrucciones.
e

• El funcionamiento de una instrucciń se define por su efecto en el estado de ejecuciń del programa
o
o
justo cuando acaba.

• El estado de ejecuciń esta formado por los valores de las variables y los registros de todos los
o
procesos.

Ejemplos de sentencias at´micas.
o

A modo de ejemplo de instrucciones at´micas, cabe citar muchas de las instrucciones m´quina del repertorio
o
a
de un procesador, por ejemplo estas tres:
• Leer una celda de memoria y cargar su valor en ese momento en un registro del procesador
• Incrementar el valor de un registro (u otras operaciones aritm´ticas entre registros).
e
• Escribir el valor de un registro en una celda de memoria.

El resultado de estas instrucciones no depende nunca de otras intrucciones que se estń ejecutando cone
currentemente. Al finalizar, la celda de memoria o el registro tomar´ un valor concreto predecible siempre a
a
partir del estado al inicio.
• En el caso de la escritura en memoria, por ejemplo, el hardware asegura que el valor escrito(justo al
final de la ejecuciń) es siempre el que hab´ en el registro (justo al inicio de la ejecuciń).
o
ıa
o

Ejemplos de sentencias no at´micas.
o

La mayor´ de las sentencias en lenguajes de alto nivel son t´
ıa
ıpicamente no at´micas, por ejemplo, la sentencia
o

§
¦

x := x + 1 ; { incrementa el valor de la variable entera ’x’ (en RAM) en una unidad }

Para ejecutarla , el compilador o int´rprete podr´ usar una secuencia de tres sentencias como esta:
e
ıa
1. leer el valor de x y cargarlo en un registro r del procesador

2. incrementar en un unidad el valor almacenado en el registro r
3. escribir el valor del registro r en la variable x

El resultado (es decir, el valor que toma x justo al acabar) depende de que haya o no haya otras sentencias
ejecutńdose a la vez y escribiendo simultńeamente sobre la variable x. Podr´ ocurrir que el valor al final
a
a
ıa
no sea igual al valor al empezar m´s uno.
a
a

¤
¥

o

Interfoliaciń de sentencias at´micas
o
o

Supongamos que definimos un programa concurrente C compuesto de dos procesos secuenciales PA y PB
que se ejecutan a la vez.

La ejecuciń de C puede dar lugar a cualquiera de las posibles mezclas (interfoliaciones) de sentencias
o
at´micas de PA y PB .
o
Pr.
PA
PB
C
C
C
C
C

Posibles secuencias de instr. at´micas
o
A1 A2 A3 A4 A5
B1 B2 B3 B4 B5
A1 A2 A3 A4 A5 B1 B2 B3 B4 B5
B1 B2 B3 B4 B5 A1 A2 A3 A4 A5
A1 B1 A2 B2 A3 B3 A4 B4 A5 B5
B1 B2 A1 B3 B4 A2 B5 A3 A4 A5
⋯

las sentencias at´micas se ordenan en funciń del instante en el que acaban (que es cuando tienen efecto)
o
o
Abstracciń
o

El modelo basado en el estudio de todas las posibles secuencias de ejecuciń entrelazadas de los procesos
o
constituye una abstracciń sobre las circunstancias de la ejecuciń de los programas concurrentes, ya que:
o
o
• Se consideran exclusivamente las caracter´
ısticas relevantes que determinan el resultado del c´lculo
a
• Esto permite simplificar el an´lisis o creaciń de los programas concurrentes.
a
o

Se ignoran los detalles no relevantes para el resultado, como por ejemplo:
• las areas de memoria asignadas a los procesos
´
• los registros particulares que estń usando
a

• el costo de los cambios de contexto entre procesos
• la pol´
ıtica del S.O. relativa a asignaciń de CPU
o

• las diferencias entre entornos multiprocesador o monoprocesador
• ....

Independencia del entorno de ejecuciń
o

El entrelazamiento preserva la consistencia

El resultado de una instrucciń individual sobre un dato no depende de las circunstancias de la ejecuciń.
o
o

Supongamos que un programa P se compone de dos instrucciones at´micas, I0 e I1 , que se ejecutan concuro
rentemente, P I0 I1 , entonces:

a

o

• Si I0 e I1 no acceden a la misma celda de memoria o registro, el orden de ejecuciń no afecta al
o
resultado final.
• Si I0 ≡ M ← 1 y I1 ≡ M ← 2, la unica suposiciń razonable es que el resultado sea consistente. Por
´
o
tanto, al final M = 1 ´ M = 2, pero nunca por ejemplo M = 3.
o

En caso contrario, ser´ imposible razonar acerca de la correcciń de los programas concurrentes.
ıa
o
Velocidad de ejecuciń de los procesos. Hip´tesis del progreso finito
o
o
Progreso Finito

No se puede hacer ninguna suposiciń acerca de las velocidades absolutas/relativas de ejecuciń de los
o
o
procesos, salvo que es mayor que cero.
Un programa concurrente se entiende en base a sus componentes (procesos) y sus interacciones, sin tener
en cuenta el entorno de ejecuciń.
o
Ejemplo: Un disco es m´s lento que una CPU pero el programa no deber´ asumir eso en el diseõ del
a
ıa
n
programa.
Si se hicieran suposiciones temporales:

• Ser´ dif´ detectar y corregir fallos
ıa ıcil

• La correcciń depender´ de la configuraciń de ejecuciń, que puede cambiar
o
ıa
o
o

Hip´tesis del progreso finito
o

Si se cumple la hip´tesis, la velocidad de ejecuciń de cada proceso ser´ no nula, lo cual tiene estas dos
o
o
a
consecuencias:
Punto de vista global

Durante la ejecuciń de un programa concurrente, en cualquier momento existir´ al menos 1 proceso
o
a
preparado, es decir, eventualmente se permitir´ la ejecuciń de algń proceso.
a
o
u
Punto de vista local

Cuando un proceso concreto de un programa concurrente comienza la ejecuciń de una sentencia, completar´
o
a
la ejecuciń de la sentencia en un intervalo de tiempo finito.
o
Estados e historias de ejecuciń de un programa concurrente
o
Estado de un programa concurrente

Valores de las variables del programa en un momento dado. Incluyen variables declaradas expl´
ıcitamente y
variables con informaciń de estado oculta (contador del programa, registros,...).
o

Un programa concurrente comienza su ejecuciń en un estado inicial y los procesos van modificando el
o
estado conforme se van ejecutando sus sentencias at´micas (producen transiciones entre dos estados de
o
forma indivisible).
Historia o traza de un programa concurrente

Secuencia de estados s0 → s1 → . . . → sn , producida por una secuencia concreta de interfoliaciń.
o

a

o

Notaciones para expresar ejecuciń concurrente
o

• Propuestas Iniciales: no separan la definiciń de los procesos de su sincronizaciń.
o
o
• Posteriores Propuestas: separan conceptos e imponen estructura.

• Declaraciń de procesos: rutinas espec´
o
ıficas de programaciń concurrente
o
grama concurrente m´s clara.
a

⇒ Estructura del pro-

Sistemas Est´ticos
a

• N´mero de procesos fijado en el fuente del programa.
u
• Los procesos se activan al lanzar el programa

• Ejemplo: Message Passing Interface (MPI-1).

Sistemas Din´micos
a

• N´mero variable de procesos/hebras que se pueden activar en cualquier momento de la ejecuciń.
u
o
• Ejemplos: OpenMP, PThreads, Java Threads, MPI-2.

Grafo de Sincronizaciń
o

• Es un Grafo Dirigido Ac´
ıclico (DAG) donde cada nodo representa una secuencia de sentencias del
programa (actividad). Dadas dos actividades, A y B, una arista conectando A en direcciń hacia B
o
significa que B no puede comenzar su ejecuciń hasta que A haya finalizado.
o
P0

P1

P3

P2
P5

P4
P6

P7

• Muestra las restricciones de precedencia que determinan cuńdo una actividad puede empezar en un
a
programa.
• Tiene que ser ac´
ıclico.

a

o
Definiciń est´tica de procesos
o
a

El n´mero de procesos (arbitrario) y el c´digo que ejecutan no cambian entre ejecuciones. Cada proceso se
u
o
asocia con su identificador y su c´digo mediante la palabra clave process
o
§
var ....

{ vars. compartidas }

¤

process NomUno ;
var ....
{ vars. locales }
begin
....
{ codigo }
end

process NomDos ;
var ....
{ vars. locales }
begin
....
{ codigo }
end
...
{ otros procesos }
¦

inicio

NomUno

NomDos

fin

¥

el programa acaba cuando acaban todos los procesos. Las vars. compartidas se iniciaizan antes de comenzar
ningń proceso.
u
Definiciń est´tica de vectores de procesos
o
a

Se pueden usar definiciones est´ticas de grupos de procesos similares que solo se diferencia en el valor de
a
una constante (vectores de procesos)
§
var ....

{ vars. compartidas }

¤

process NomP[ ind : a..b ] ;
var ....
{ vars. locales }
begin
....
{ codigo }
....
{ aqui ind vale a, a + 1,...,b }
end
...
¦

{ otros procesos }

inicio
NomP[a]

....

NomP[b]

fin
¥

• En cada caso, a y b se traducen por dos constantes concretas (el valor de a ser´ t´
a ıpicamente 0 o 1).

• El n´mero total de procesos ser´ b − a + 1 (se supone que a <= b)
u
a

Creaciń de procesos no estructurada con fork-join.
o

• fork: sentencia que especifica que la rutina nombrada puede comenzar su ejecuciń, al mismo tiempo
o
que comienza la sentencia siguiente (bifurcaciń).
o

• join: sentencia que espera la terminaciń de la rutina nombrada, antes de comenzar la sentencia
o
siguiente (uniń).
o

a

o
§
procedure P1 ;
begin
A ;
fork P2 ;
B ;
join P2 ;
C ;
end
¦

¤

§
procedure P2 ;
begin
D ;
end
¦

¤

A
A

fork
B
¥

D

B

join

D
C

C

¥

• Ventajas: prćtica y potente, creaciń din´mica.
a
o
a

• Inconvenientes: no estructuraciń, dif´ comprensiń de los programas.
o
ıcil
o

Creaciń de procesos estructurada con cobegin-coend
o

Las sentencias en un bloque delimitado por cobegin-coend comienzan su ejecuciń todas ellas a la vez:
o
• en el coend se espera a que se terminen todas las sentencias.
• Hace expl´
ıcito qu´ rutinas van a ejecutarse concurrentemente.
e
§
begin
A ;
cobegin
B ; C ; D ;
coend
E ;
end
¦

¤

A

cobegin
B

C

A

D

B

E

• Ventajas: impone estructura: 1 unica entrada y 1 unica salida
´
´
• Inconveniente: menor potencia expresiva que fork-join.

2.3

D

E

coend
¥

C

⇒ m´s fćil de entender.
a a

Exclusiń mutua y sincronizaciń
o
o

Exclusiń mutua y sincronizaciń
o
o

Segń el modelo abstracto, los procesos concurrentes ejecutan sus instrucciones at´micas de forma que,
u
o
en principio, es completamente arbitrario el entremezclado en el tiempo de sus respectivas secuencias de
instrucciones. Sin embargo, en un conjunto de procesos que no son independientes entre s´ (es decir, son
ı
cooperativos), algunas de las posibles formas de combinar las secuencias no son v´lidas.
a
• en general, se dice que hay una condiciń de sincronizaciń cuando esto ocurre, es decir, que hay
o
o
alguna restricciń sobre el orden en el que se pueden mezclar las instrucciones de distintos procesos.
o

• un caso particular es la exclusiń mutua, son secuencias finitas de instrucciones que un proceso debe
o
ejecutar de principio a fin sin mezclarse con otras (o las mismas) de otros procesos.

a

o

2.3.1

Concepto de exclusiń mutua
o

Exclusiń mutua
o

La restricciń se refiere a una o varias secuencias de instrucciones consecutivas que aparecen en el texto de
o
uno o varios procesos.
• Al conjunto de dichas secuencias de instrucciones se le denomina secciń cr´
o
ıtica (SC).

• Ocurre exclusiń mutua (EM) cuando los procesos solo funcionan correctamente si, en cada instante
o
de tiempo, hay como mucho uno de ellos ejecutando cualquier instrucciń de la secciń cr´
o
o
ıtica.

es decir, el solapamiento de las instrucciones debe ser tal que cada secuencia de instrucciones de la SC se
ejecuta como mucho por un proceso de principio a fin, sin que (durante ese tiempo) otros procesos ejecuten
ninguna de esas instrucciones ni otras de la misma SC.
Ejemplos de exclusiń mutua
o

El ejemplo t´
ıpico de EM ocurre en procesos con memoria compartida que acceden para leer y modificar
variables o estructuras de datos comunes usando operaciones no at´micas (es decir, compuestas de varias
o
instrucciones m´quina o elementales que pueden solaparse con otras secuencias), aunque hay muchos otros
a
ejemplos:

• env´ de datos a dispositivos que no se pueden compartir (p.ej., el bucle que env´ una secuencia de
ıo
ıa
datos que forma un texto a una impresora o cualquier otro dispositivo de salida v´ el bus del sistema).
ıa
• recepciń de datos desde dispositivos (p.ej., un bucle que lee una secuencia de pulsaciones de teclas
o
desde el teclado, tambiń a trav´s del bus).
e
e

Un ejemplo sencillo de exclusiń mutua
o

Para ilustrar el problema de la EM, veremos un ejemplo sencillo que usa una variable entera (x) en memoria
compartida y operaciones aritm´ticas elementales.
e
• La secciń cr´
o
ıtica esta formada por todas las secuencias de instrucciones m´quina que se obtienen al
a
traducir (compilar) operaciones de escritura (o lectura y escritura) de la variable (p.ej., asignaciones
como x:=x+1 o x:=4∗z).
• Veremos que si varios procesos ejecutan las instrucciones m´quina de la secciń cr´
a
o
ıtica de forma
simultńea, los resultados de este tipo de asignaciones son indeterminados.
a

aqu´ el t´rmino indeterminado indica que para cada valor de x (o del resto de variables) previo a cada
ı,
e
asignaciń, existe un conjunto de valores distintos posibles de x al finalizar la ejecuciń de dicha asignaciń
o
o
o
(el valor concreto que toma x depende del orden de entremezclado de las instrucciones m´quina).
a
Traducciń y ejecuciń de asignaciones
o
o

Si consideramos la instrucciń x:=x+1 (que forma la SC), veremos que una traducciń t´
o
o ıpica a c´digo
o
m´quina tendr´ estas tres instrucciones:
a
ıa
a

o
1.

load ri ← x

3.

store ri → x

2.

add ri , 1

cargar el valor de la variable x en un registro r de la CPU (por el
proceso n´mero i).
u
incrementar en una unidad el valor del registro r

guardar el valor del registro r en la posiciń de memoria de la vario
able x.

• hay dos procesos concurrentes (P0 y P1 ) que ejecutan la asignaciń, y por tanto las tres instrucciones
o
m´quina se pueden entremezclar de forma arbitraria.
a

• cada proceso mantiene su propia copia del registro r (los llamaremos r0 y r1 )

• ambos comparten x, cuyos accesos v´ load y store son at´micos pues bloquean el bus del sistema.
ıa
o

Posibles secuencias de instrucciones

Suponemos que inicialmente x vale 0 y ambos procesos ejecutan la asignaciń, puede haber varias secuencias
o
de interfoliaciń, aqu´ vemos dos:
o
ı
P0
load r0 ← x
add r0 , 1
store r0 → x

P1

load r1 ← x
add r1 , 1
store r1 → x

x
0
0
1
1
1
2

P0
load r0 ← x
add r0 , 1

store r0 → x

P1

load r1 ← x
add r1 , 1

store r1 → x

x
0
0
0
0
1
1

por tanto, partiendo de x== 0, tenemos al final que la variable puede tomar el valor 1 o 2 dependiendo del
orden de ejecuciń de las instrucciones.
o

2.3.2

Condiciń de sincronizaciń
o
o

Condiciń de sincronizaciń.
o
o

En general, en un programa concurrente compuesto de varios procesos, una condiciń de sincronizaciń
o
o
establece que:
no son correctas todas las posibles interfoliaciones de las secuencias de instrucciones at´micas
o
de los procesos.

• esto ocurre t´
ıpicamente cuando, en un punto concreto de su ejecuciń, uno o varios procesos deben
o
esperar a que se cumpla una determinada condiciń global (depende de varios procesos).
o

Veremos un ejemplo sencillo de condiciń de sincronizaciń en el caso en que los procesos puedan usar
o
o
variables comunes para comunicarse (memoria compartida). En este caso, los accesos a las variables no
pueden ordenarse arbitrariamente (p.ej.: leer de ella antes de que sea escrita)

a

o

Ejemplo de sincronizaciń. Productor Consumidor
o

Un ejemplo t´
ıpico es el de dos procesos cooperantes en los cuales uno de ellos (productor) produce una
secuencia de valores (p.ej. enteros) y el otro (consumidor) usa cada uno de esos valores. La comunicaciń
o
se hace v´ la variable compartida x.:
ıa

§
{ variables compartidas }
var x : integer ; { contiene cada valor producido }
¦
§
{ Proceso productor: calcula ’ x ’ }
process Productor ;
var a : integer ; { no compartida }
begin
while true do begin
{ calcular un valor }
a := ProducirValor() ;
{ escribir en mem. compartida }
x := a ; { sentencia E }
end
end
¦

¤
§
{ Proceso Consumidor: lee ’ x ’ }
process Consumidor ;
var b : integer ; { no compartida }
begin
while true do begin
{ leer de mem. compartida }
b := x ; { sentencia L }
{ utilizar el valor leido }
UsarValor(b) ;
end
end
¥
¦

Secuencias correctas e incorrectas

Los procesos descritos solo funcionan como se espera si el orden en el que se entremezclan las sentencias
elementales etiquetadas como E (escritura) y L (lectura) es: E, L, E, L, E, L, . . ..

• L, E, L, E, . . . es incorrecta: se hace una lectura de x previa a cualquier escritura (se lee valor indeterminado).

• E, L, E, E, L, . . . es incorrecta: hay dos escrituras sin ninguna lectura entre ellas (se produce un valor
que no se lee).
• E, L, L, E, L, . . . es incorrecta: hay dos lecturas de un mismo valor, que por tanto es usado dos veces.

La secuencia v´lida asegura la condiciń de sincronizaciń:
a
o
o

• Consumidor no lee hasta que Productor escriba un nuevo valor en x (cada valor producido es usado
una sola vez).

• Productor no escribe un nuevo valor hasta que Consumidor lea el ultimo valor almacenado en x (ningń
´
u
valor producido se pierde).

2.4

2.4.1

Propiedades de los sistemas concurrentes
Correcciń de un sistema concurrente
o

Concepto de correcciń de un programa concurrente
o

Propiedad de un programa concurrente: Atributo del programa que es cierto para todas las posibles
secuencias de interfoliaciń (historias del programa).
o
a

¤
¥
¤

¥

o
Hay 2 tipos:

• Propiedad de seguridad (safety).

• Propiedad de vivacidad (liveness).

2.4.2

Propiedades de seguridad y vivacidad

Propiedades de Seguridad (Safety)

• Son condiciones que deben cumplirse siempre del tipo: Nunca pasar´ nada malo.
a
• Requeridas en especificaciones est´ticas del programa.
a

• Similar a correcciń parcial en programas secuenciales: “Si el programa termina, las respuestas deben
o
ser correctas.
• Son fćiles de demostrar y para cumplirlas se suelen restringir las posibles interfoliaciones.
a

Ejemplos:

• Exclusiń mutua: 2 procesos nunca entrelazan ciertas subsecuencias de operaciones.
o

• Ausencia Interbloqueo (Deadlock-freedom): Nunca ocurrir´ que los procesos se encuentren esperando
a
algo que nunca suceder´.
a

• Propiedad de seguridad en el Productor-Consumidor El consumidor debe consumir todos los datos
producidos por el productor en el orden en que se van produciendo.

Propiedades de Vivacidad (Liveness)

• Deben cumplirse eventualmente.

• Son propiedades din´micas dif´
a
ıciles de probar: Realmente sucede algo bueno

Ejemplos:

• Ausencia de inaniciń (starvation-freedom): Un proceso o grupo de procesos no puede ser indefinidao
mente pospuesto. En algń momento, podr´ avanzar.
u
a

• Equidad (fairness): Tipo particular de prop. de vivacidad. Un proceso que desee progresar debe
hacerlo con justicia relativa con respecto a los dem´s. M´s ligado a la implementaciń y a veces
a
a
o
incumplida: existen distintos grados.

a

o

2.5

2.5.1

Verificaciń de programas concurrentes
o

Verificaciń de programas concurrentes. Introducciń
o
o

Verificaciń de programas concurrentes. Introducciń
o
o

¿ C´mo demostrar que un programa cumple una determinada propiedad ?
o

• Posibilidad: realizar diferentes ejecuciones del programa y comprobar que se verifica la propiedad.

• Problema: S´lo permite considerar un n´mero limitado de historias de ejecuciń y no demuestra que
o
u
o
no existan casos indeseables.
• Ejemplo: Comprobar que el proceso P produce al final x = 3:
§
process P ;
var x : integer := 0 ;
cobegin
x := x+1 ; x := x+2 ;
coend
¦

¤

¥

Hay varias historias que llevan a x==1 o x==2 (la asignaciń no es at´mica), pero estas historias
o
o
podr´ no aparecer dentro de un n´mero limitado de ejecuciones.
ıan
u

Verificaciń de programas concurrentes. Enfoque operacional
o

• Enfoque operacional: An´lisis exhaustivo de casos. Se chequea la correcciń de todas las posibles
a
o
historias.
• Problema: Su utilidad est´ muy limitada cuando se aplica a programas concurrentes complejos ya que
a
el n´mero de interfoliaciones crece exponencialmente con el n´mero de instrucciones de los procesos.
u
u

• Para el sencillo programa P (2 procesos, 3 sentencias at´micas por proceso) habr´ que estudiar 20
o
ıa
historias disferentes.

2.5.2

Enfoque axiom´tico para la verificaciń
a
o

Verificaciń. Enfoque axiom´tico
o
a

• Se define un sistema l´gico formal que permite establecer propiedades de programas en base a axiomas
o
y reglas de inferencia.

• Se usan f´rmulas l´gicas (asertos) para caracterizar un conjunto de estados.
o
o

• Las sentencias at´micas actán como transformadores de predicados (asertos). Los teoremas en la
o
u
l´gica tienen la forma:
o
a

o
{P}

S

{Q}

“Si la ejecuciń de la sentencia S empieza en algń estado que hace verdadero el predicado P (preo
u
condiciń), entonces el predicado Q (poscondiciń) ser´ verdadero en el estado resultante.
o
o
a

• Menor Complejidad: El trabajo que conlleva la prueba de correcciń es proporcional al n´mero de
o
u
sentencias at´micas en el programa.
o

Invariante global

• Invariante global: Predicado que referencia variables globales siendo cierto en el estado inicial de
cada proceso y mantenińdose cierto ante cualquier asignaciń dentro de los procesos.
e
o
• En una soluciń correcta del Productor-Consumidor, un invariante global ser´
o
ıa:
consumidos ≤ producidos ≤ consumidos + 1

Bibliograf´ del tema 1.
ıa

Para m´s informaciń, ejercicios, bibliograf´ adicional, se puede consultar:
a
o
ıa
1.1. Conceptos b´sicos y Motivaciń Palma (2003), cap´
a
o
ıtulo 1.

1.2. Modelo abstracto y Consideraciones sobre el hardware Ben-Ari (2006), cap´
ıtulo 2. Andrews (2000)
cap´
ıtulo 1. Palma (2003) cap´
ıtulo 1.
1.3. Exclusiń mutua y sincronizaciń Palma (2003), cap´
o
o
ıtulo 1.

1.4. Propiedades de los Sistemas Concurrentes Palma (2003), cap´
ıtulo 1.

1.5. Verificaciń de Programas concurrentes Andrews (2000), cap´
o
ıtulo 2.

2.6

1

Problemas del tema 1.

Considerar el siguiente fragmento de programa para 2 procesos P1 y P2 :

Los dos procesos pueden ejecutarse a cualquier velocidad. ¿ Cu´les son los posibles valores resultantes para
a
x ?. Suponer que x debe ser cargada en un registro para incrementarse y que cada proceso usa un registro
diferente para realizar el incremento.

a

o

§
{ variables compartidas }
var x : integer := 0 ;
¦
§
process P1 ;
var i : integer ;
begin
for i := 1 to 2 do begin
x := x+1 ;
end
end
¦

¤
¤
§
process P2 ;
var j : integer ;
begin
for j := 1 to 2 do begin
x := x+1 ;
end
end
¥
¦

¥
¤

¥

2

¿ C´mo se podr´ hacer la copia del fichero f en otro g, de forma concurrente, utilizando la instrucciń
o
ıa
o
concurrente cobegin-coend ? . Para ello, suponer que:

• los archivos son secuencia de items de un tipo arbitrario T, y se encuentran ya abiertos para lectura
(f) y escritura (g). Para leer un ´
ıtem de f se usa la llamada a funciń leer(f) y para saber si se han
o
le´ todos los ´
ıdo
ıtems de f, se puede usar la llamada fin(f) que devuelve verdadero si ha habido al
menos un intento de leer cuando ya no quedan datos. Para escribir un dato x en g se puede usar la
llamada a procedimiento escribir(g,x).
• El orden de los ´
ıtems escritos en g debe coincidir con el de f.

• Dos accesos a dos archivos distintos pueden solaparse en el tiempo.

3

Construir, utilizando las instrucciones concurrentes cobegin-coend y fork-join, programas concurrentes
que se correspondan con los grafos de precedencia que se muestran a continuaciń:
o

a

o

4

Dados los siguientes fragmentos de programas concurrentes, obtener sus grafos de precedencia asociados:
§
begin
P0 ;
cobegin
P1 ;
P2 ;
cobegin
P3 ; P4 ; P5 ; P6 ;
coend
P7 ;
coend
P8;
end
¦

¤
§
begin
P0 ;
cobegin
begin
cobegin
P1;P2;
coend
P5;
end
begin
cobegin
P3;P4;
¥
coend
P6;
end
coend
P7 ;
end
¦

¤

¥

5

Suponer un sistema de tiempo real que dispone de un captador de impulsos conectado a un contador de
energ´ elćtrica. La funciń del sistema consiste en contar el n´mero de impulsos producidos en 1 hora
ıa e
o
u
(cada Kwh consumido se cuenta como un impulso) e imprimir este n´mero en un dispositivo de salida. Para
u
ello se ha de escribir un programa concurrente con 2 procesos: un proceso acumulador (lleva la cuenta de
los impulsos recibidos) y un proceso escritor (escribe en la impresora). En la variable comń a los 2 procesos
u
n se lleva la cuenta de los impulsos. Suponiendo que el sistema se encuentra en un estado correspondiente
al valor de la variable n = N y en estas condiciones se presentan simultńeamente un nuevo impulso y el
a
final del periodo de 1 hora, obtener las posibles secuencias de ejecuciń de los procesos y cu´les de ellas
o
a
son correctas.
Suponer que el proceso acumulador puede invocar un procedimiento Espera_impulso para esperar a que
llegue un impulso, y que el proceso escritor puede llamar a Espera_fin_hora para esperar a que termine
una hora.

En el enunciado se usan sentencias de acceso a la variable n encerradas entre los s´
ımbolos < y >. Esto
significa que cada una de esas sentencias se ejecuta en exclusiń mutua entre los dos procesos, es decir,
o
esas sentencias se ejecutan de principio a fin sin entremezclarse entre ellas.

a

o

6

Supongamos que tenemos un vector a en memoria compartida (de tamaõ par, es decir de tamaõ 2n para
n
n
algń n > 1), y queremos obtener en otro vector b una copia ordenada de a. Podemos usar una llamada a
u
procedimiento de la forma sort(s,t) para ordenar un segmento de a (el que va desde s hasta t, ambos
incluidos) de dos formas: (a) para ordenar todo el vector de forma secuencial con sort(1,2n);b:=a o bien
(b) para ordenar las dos mitades de a de forma concurrente, y despu´s mezclar dichas dos mitades en un
e
segundo vector b (para mezclar usamos un procedimiento merge). A continuaciń se encuentra una posible
o
versiń del c´digo:
o
o
§
¤
var a,b : array[1..2*n] of integer ; { n es una constante predefinida }
var uc : array[1..2] of integer ;
{ ultimo completado de cada mitad }
¦
¥
§
¤
§
¤
procedure Secuencial() ;
{ ordena el segmento de a entre s y t }
var i : integer ;
begin
procedure Sort( mitad, s, t : integer )
Sort(1,1,2n) ; {ord. a}
var i, j : integer ;
for i := 1 to 2*n do {copia a en b}
begin
b[i] := a[i] ;
for i := s to t do begin
end
for j:= s+1 to t do
procedure Concurrente() ;
if a[i] <= a[j] then
begin
swap( a[i], b[j] ) ;
cobegin
uc[mitad] := i ;
Sort(1,1,n-1);
end
Sort(2,n,2*n);
end
¦
¥
coend
Merge(1,n+1,2*n);
end
¦
¥

El c´digo de Merge se encarga de ir leyendo las dos mitades y en cada paso seleccionar el menor elemento
o
de los dos siguientes por leer en a (uno en cada mitad), y escribir dicho menor elemento en el vector mezclado
b. El c´digo es el siguiente:
o

a

o

§
procedure Merge( inferior, medio, superior: integer ) ;
var k, c1, c2, ind1, ind2 : integer;
begin
{ k es la siguiente posicion a escribir en b }
k:=1 ;
{ c1 y c2 indican siguientes elementos a mezclar en cada mitad }
c1 := inferior ;
c2 := medio ;
{ mientras no haya terminado con la primera mitad }
while c1 < medio do
begin
if a[c1] < a[c2] then begin { minimo en la primera mitad }
b[k] := a[c1] ;
k
:= k+1 ;
c1
:= c1+1 ;
if c1 >= medio then { Si fin prim. mitad, copia la segunda }
for ind2 := c2 to superior do begin
b[k] := a[ind2] ;
k
:= k+1 ;
end
end
else begin { minimo en la segunda mitad }
b[k] := a[c2] ;
k
:= k+1 ;
c2
:= c2+1 ;
if c2 >= superior then begin { Si fin segunda mitad, copia primera }
for ind1 := c1 to medio do begin
b[k] := a[ind2] ;
k:=k+1;
end
c1 := medio ; { fuerza terminacion del while }
end
end
end
end
¦

¤

¥

Llamaremos Ts (k) al tiempo que tarda el procedimiento Sort cuando actua sobre un segmento del vector
con k entradas. Suponemos que el tiempo que (en media) tarda cada iteraciń del bucle interno que hay en
o
Sort es la unidad (por definiciń). Es evidente que ese bucle tiene k(k − 1)/2 iteraciones, luego:
o
Ts (k) =

k(k − 1)
2

=

1 2 1
k − k
2
2

El tiempo que tarda la versiń secuencial sobre 2n elementos (llamaremos S a dicho tiempo) ser´ evidenteo
a
mente Ts (2n), luego
1
1
S = Ts (2n) =
(2n)2 − (2n) = 2n2 − n
2
2
con estas definiciones, calcula el tiempo que tardar´ la versiń paralela, en dos casos:
a
o

(1) Las dos instancias concurrentes de Sort se ejecutan en el mismo procesador (llamamos P1 al tiempo
que tarda).
a

o

(2) Cada instancia de Sort se ejecuta en un procesador distinto (lo llamamos P2 )

escribe una comparaciń cualitativa de los tres tiempos (S,P1 y P2 ).
o

Para esto, hay que suponer que cuando el procedimiento Merge actua sobre un vector con p entradas, tarda
p unidades de tiempo en ello, lo cual es razonable teniendo en cuenta que en esas circunstancias Merge
copia p valores desde a hacia b. Si llamamos a este tiempo Tm (p), podemos escribir
Tm (p) = p

.

7

Supongamos que tenemos un programa con tres matrices (a,b y c) de valores flotantes declaradas como
variables globales. La multiplicaciń secuencial de a y b (almacenando el resultado en c) se puede hacer
o
mediante un procedimiento MultiplicacionSec declarado como aparece aqu´
ı:
§
var a, b, c : array[1..3,1..3] of real ;

procedure MultiplicacionSec()
var i,j,k : integer ;
begin
for i := 1 to 3 do
for j := 1 to 3 do begin
c[i,j] := 0 ;
for k := 1 to 3 do
c[i,j] := c[i,j] + a[i,k]*b[k,j] ;
end
end
¦

¤

¥

Escribir un programa con el mismo fin, pero que use 3 procesos concurrentes. Suponer que los elementos de
las matrices a y b se pueden leer simultńeamente, as´ como que elementos distintos de c pueden escribirse
a
ı
simultńeamente.
a

8

Un trozo de programa ejecuta nueve rutinas o actividades (P1 , P2 , . . . , P9 ), repetidas veces, de forma concurrentemente con cobegin coend (ver la figura de la izquierda), pero que requieren sincronizarse segń
u
determinado grafo (ver la figura de la derecha):

a

SCD (13-14). Tema 2. Sincronizaciń en memoria compartida..
o
Trozo de programa:

§
while true do
cobegin
P1 ; P2 ; P3 ;
P4 ; P5 ; P6 ;
P7 ; P8 ; P9 ;
coend
¦

Grafo de sincronizaciń:
o

¤

P11
P

P33
P

P44
P

¥

P22
P
P55
P

P66
P

P77
P

P88
P

P99
P

Supń que queremos realizar la sincronizaciń indicada en el grafo, usando para ello llamadas desde cada
o
o
rutina a dos procedimientos (EsperarPor y Acabar). Se dan los siguientes hechos:

• El procedimiento EsperarPor(i) es llamado por una rutina cualquiera (la n´mero k) para esperar a
u
que termine la rutina n´mero i, usando espera ocupada. Por tanto, se usa por la rutina k al inicio
u
para esperar la terminaciń de las otras rutinas que corresponda segń el grafo.
o
u
• El procedimiento Acabar(i) es llamado por la rutina n´mero i, al final de la misma, para indicar que
u
dicha rutina ya ha finalizado.
• Ambos procedimientos pueden acceder a variables globales en memoria compartida.

• Las rutinas se sincronizan unica y exclusivamente mediante llamadas a estos procedimientos, siendo
´
la implementaciń de los mismos completamente transparente para las rutinas.
o

Escribe una implementaciń de EsperarPor y Acabar (junto con la declaraciń e inicializaciń de las
o
o
o
variables compartidas necesarias) que cumpla con los requisitos dados.

a

Chapter 3

Tema 2. Sincronizaciń en memoria
o
compartida.
3.1

Introducciń a la sincronizaciń en memoria compartida.
o
o

Sincronizaciń en memoria compartida
o

En esta tema estudiaremos soluciones para exclusiń mutua y sincronizaciń basadas en el uso de memoria
o
o
compartida entre los procesos involucrados. Este tipo de soluciones se pueden dividir en dos categor´
ıas:

• Soluciones de bajo nivel con espera ocupada estń basadas en programas que contienen expl´
a
ıcitamente
instrucciones de bajo nivel para lectura y escritura directamente a la memoria compartida, y bucles
para realizar las esperas.

• Soluciones de alto nivel partiendo de las anteriores, se diseã una capa software por encima que
n
ofrece un interfaz para las aplicaciones. La sincronizaciń se consigue bloqueando un proceso cuando
o
deba esperar.

Soluciones de bajo nivel con espera ocupada

Cuando un proceso debe esperar a que ocurra un evento o sea cierta determinada condiciń, entra en un
o
bucle indefinido en el cual continuamente comprueba si la situaciń ya se da o no (a esto se le llama espera
o
ocupada). Este tipo de soluciones se pueden dividir en dos categor´
ıas:

• Soluciones software: se usan operaciones estńdar sencillas de lectura y escritura de datos simples
a
(t´
ıpicamente valores l´gicos o enteros) en la memoria compartida
o

• Soluciones hardware (cerrojos): basadas en la existencia de instrucciones m´quina espec´
a
ıficas dentro
del repertorio de instrucciones de los procesadores involucrados

Soluciones de alto nivel

Las soluciones de bajo nivel con espera ocupada se prestan a errores, producen algoritmos complicados y
tienen un impacto negativo en la eficiencia de uso de la CPU (por los bucles). En las soluciones de alto
nivel se ofrecen interfaces de acceso a estructuras de datos y adem´s se usa bloqueo de procesos en lugar
a
de espera ocupada. Veremos algunas de estas soluciones:
43

o

• Sem´foros: se construyen directamente sobre las soluciones de bajo nivel, usando adem´s servicios
a
a
del SO que dan la capacidad de bloquear y reactivar procesos.

• Regiones cr´
ıticas condicionales: son soluciones de m´s alto nivel que los sem´foros, y que se pueden
a
a
implementar sobre ellos.
• Monitores: son soluciones de m´s alto nivel que las anteriores y se pueden implementar en algunos
a
lenguajes orientados a objetos como Java o Python.

3.1.1

Estructura de los procesos con Secciones Cr´
ıticas

Entrada y salida en secciones cr´
ıticas

Para analizar las soluciones a EM asumimos que un proceso que incluya un bloque considerado como secciń
o
cr´
ıtica (SC) tendr´ dicho bloque estructurado en tres etapas:
a

1. protocolo de entrada (PE): una serie de instrucciones que incluyen posiblemente espera, en los casos
en los que no se pueda conceder acceso a la secciń cr´
o
ıtica.
2. secciń cr´
o
ıtica (SC): instrucciones que solo pueden ser ejecutadas por un proceso como mucho.

3. protocolo de salida (PS): instrucciones que permiten que otros procesos puedan conocer que este
proceso ha terminado la secciń cr´
o
ıtica.

Todas las sentencias que no forman parte de ninguna de estas tres etapas se denominan resto de sentencias
(RS) .
Acceso repetitivo a las secciones cr´
ıticas

En general, un proceso puede contener m´s de una secciń cr´
a
o
ıtica, y cada secciń cr´
o
ıtica puede estar
desglosada en varios bloques de c´digo separados en el texto del proceso. Para simplificar el an´lisis,
o
a
suponemos, sin p´rdida de generalidad, que:
e
• Cada proceso tiene una unica secciń cr´
´
o
ıtica.

• Dicha secciń cr´
o
ıtica est´ formada por un unico bloque contiguo de instrucciones.
a
´
• El proceso es un bucle infinito que ejecuta en cada iteracciń dos pasos:
o
◾ Secciń cr´
o
ıtica (con el PE antes y el PS despu´s)
e

◾ Resto de sentencias: se emplea un tiempo arbitrario no acotado, e incluso el proceso puede
finalizar en esta secciń, de forma prevista o imprevista.
o

de esta forma se prevee el caso m´s general en el cual no se supone nada acerca de cuantas veces un
a
proceso puede intentar entrar en una SC.

a

o
Condiciones sobre el comportamiento de los procesos.

Para que se puedan implementar soluciones correctas al problema de EM, es necesario suponer que:

Los procesos siempre terminan una secciń cr´
o
ıtica y emplean un intervalo de tiempo finito desde
que la comienzan hasta que la terminan.

es decir, durante el tiempo en que un proceso se encuentra en una secciń cr´
o
ıtica nunca
• Finaliza o aborta.

• Es finalizado o abortado externamente.
• Entra en un bucle infinito.

• Es bloqueado o suspendido indefinidamente de forma externa.

en general, es deseable que el tiempo empleado en las secciones cr´
ıticas sea el menor posible, y que las
instrucciones ejecutadas no puedan fallar.

3.1.2

Propiedades para exclusiń mutua
o

Propiedades requeridas para las soluciones a EM

Para que un algoritmo para EM sea correcto, se deben cumplir cada una de estas tres propiedades m´
ınimas:
1. Exclusiń mutua
o
2. Progreso

3. Espera limitada

adem´s, hay propiedades deseables adicionales que tambiń deben cumplirse:
a
e
4. Eficiencia
5. Equidad

si bien consideramos correcto un algoritmo que no sea muy eficiente o para el que no pueda demostrarse
claramente la equidad.
Exclusiń mutua
o

Es la propiedad fundamental para el problema de la secciń cr´
o
ıtica. Establece que

En cada instante de tiempo, y para cada secciń cr´
o
ıtica existente, habr´ como mucho un proceso
a
ejecutando alguna sentencia de dicha regiń cr´
o
ıtica.

En esta secciń veremos soluciones de memoria compartida que permiten un unico proceso en una secciń
o
´
o
cr´
ıtica.
Si bien esta es la propiedad fundamental, no puede conseguirse de cualquier forma, y para ello se establecen
las otras dos condiciones m´
ınimas que vemos a continuaciń.
o

a

o
Progreso

Consideremos una secciń cr´
o
ıtica en un instante en el cual no hay ningń proceso ejecutńdola, pero s´ hay
u
a
ı
uno o varios procesos en el PE compitiendo por entrar a la SC. La propiedad de progreso establece que
Un algoritmo de EM debe estar diseãdo de forma tal que
n

1. Despu´s de un intervalo de tiempo finito desde que ingres´ el primer proceso al PE, uno
e
o
de los procesos en el mismo podr´ acceder a la SC.
a

2. La selecciń del proceso anterior es completamente independiente del comportamiento de
o
los procesos que durante todo ese intervalo no han estado en SC ni han intentado acceder.

Cuando la condiciń (1) no se da, se dice que ocurre un interbloqueo, ya que todos los procesos en el PE
o
quedan en espera ocupada indefinidamente sin que ninguno pueda avanzar.
Espera limitada

Supongamos que un proceso emplea un intervalo de tiempo en el PE intentando acceder a una SC. Durante
ese intervalo de tiempo, cualquier otro proceso activo puede entrar un n´mero arbitrario de veces n a ese
u
mismo PE y lograr acceso a la SC (incluyendo la posibilidad de que n = 0). La propiedad establece que:
Un algoritmo de exclusiń mutua debe estar diseãdo de forma que n nunca ser´ superior a un
o
n
a
valor m´ximo determinado.
a

esto implica que las esperas en el PE siempre serń finitas (suponiendo que los procesos emplean un tiempo
a
finito en la SC).
Propiedades deseables: eficiencia y equidad.
Las propiedades deseables son estas dos:

• Eficiencia Los protocolos de entrada y salida deben emplear poco tiempo de procesamiento (excluyendo las esperas ocupadas del PE), y las variables compartidas deben usar poca cantidad de
memoria.

• Equidad En los casos en que haya varios procesos compitiendo por acceder a una SC (de forma
repetida en el tiempo), no deber´ existir la posibilidad de que sistem´ticamente se perjudique a
ıa
a
algunos y se beneficie a otros.

3.2

Soluciones software con espera ocupada para E.M.

Introducciń
o

En esta secciń veremos diversas soluciones para lograr exclusiń mutua en una secciń cr´
o
o
o
ıtica usando
variables compartidas entre los procesos o hebras involucrados. Estos algoritmos usan dichas variables para
hacer espera ocupada cuando sea necesario en el protocolo de entrada.
Los algoritmos que resuelven este problema no son triviales, y menos para m´s de dos procesos. En la
a
actualidad se conocen distintas soluciones con distintas propiedades.
Veremos estos algoritmos:

a

o
• Algoritmo de Dekker (para 2 procesos)

• Algoritmo de Peterson (para 2 y para un n´mero arbitrario de procesos).
u

3.2.1

Refinamiento sucesivo de Dijkstra

Introducciń al refinamiento sucesivo de Dijkstra
o

El Refinamiento sucesivo de Dijskstra hace referencia a una serie de algoritmos que intentan resolver el
problema de la exclusiń mutua.
o
• Se comienza desde una versiń muy simple, incorrecta (no cumple alguna de las propiedades), y
o
se hacen sucesivas mejoras para intentar cumplir las tres propiedades. Esto ilustra muy bien la
importancia de dichas propiedades.
• La versiń final correcta se denomina Algoritmo de Dekker
o

• Por simplicidad, veremos algoritmos para 2 procesos unicamente.
´

• Se asume que hay dos procesos, denominados Proceso 0 y Proceso 1, cada uno de ellos ejecuta un
bucle infinito conteniendo:
1. Protocolo de entrada (PE).
2. Secciń cr´
o
ıtica (SC).

3. Protocolo de salida (PS).

4. Otras sentencias del proceso (RS).

Versiń 1. Pseudoc´digo.
o
o

En esta versiń se usa una variable l´gica compartida (p01sc) que valdr´ true solo si el proceso 0 o el
o
o
a
proceso 1 estń en SC, y valdr´ false si ninguno lo est´:
a
a
a
§
{ variables compartidas y valores iniciales }
var p01sc : boolean := false ; { indica si la SC esta ocupada }
¦
§
¤
§
process P0 ;
process P1 ;
begin
begin
while true do begin
while true do begin
while p01sc do begin end
p01sc := true ;
p01sc := true ;
{ seccion critica }
{ seccion critica }
p01sc := false ;
p01sc := false ;
{ resto seccion }
{ resto seccion }
end
end
end
end
¦
¥
¦

¤
¥
¤

¥

a

o
Versiń 1. Correcciń.
o
o

Sin embargo, esa versiń no es correcta. El motivo es que no cumple la propiedad de exclusiń mutua,
o
o
pues ambos procesos pueden estar en la secciń cr´
o
ıtica. Esto puede ocurrir si ambos leen p01sc y ambos
la ven a false. es decir, si ocurre la siguiente secuencia de eventos:
1. el proceso 0 accede al protocolo de entrada, ve p01sc con valor false,

2. el proceso 1 accede al protocolo de entrada, ve p01sc con valor false,
3. el proceso 0 pone p01sc a true y entra en la secciń cr´
o
ıtica,
4. el proceso 1 pone p01sc a true y entra en la secciń cr´
o
ıtica.

o
o

Para solucionar el problema se usar´ una unica variable l´gica (turno0), cuyo valor servir´ para indicar cual
a
´
o
a
de los dos procesos tendr´ prioridad para entrar SC la pr´xima vez que llegen al PE. La variable valdr´
a
o
a
true si la prioridad es para el proceso 0, y false si es para el proceso 1:
§
var turno0 : boolean := true ; { podria ser tambien ’false’ }
¦
§
¤
§
process P0 ;
process P1 ;
begin
begin
while true do begin
while true do begin
while not turno0 do begin end
while turno0 do begin end
{ seccion critica }
{ seccion critica }
turno0 := false ;
turno0 := true ;
{ resto seccion }
{ resto seccion }
end
end
end
end
¦
¥
¦

¤
¥
¤

¥

o
o

Esta segunda versiń no es tampoco correcta, el motivo es distinto. Se dan estas circunstancias:
o

• Se cumple la propiedad de exclusiń mutua. Esto es fćil de verificar, ya que si un proceso est´ en
o
a
a
SC ha logrado pasar el bucle del protocolo de entrada y por tanto la variable turno0 tiene un valor
que forzosamente hace esperar al otro.

• No se cumple la propiedad de progreso en la ejecuciń. El problema est´ en que este esquema obliga
o
a
a los procesos a acceder de forma alterna a la secciń cr´
o
ıtica. En caso de que un proceso quiera
acceder dos veces seguidas sin que el otro intente acceder m´s, la segunda vez quedar´ esperando
a
a
indefinidamente.

Este es un buen ejemplo de la necesidad de tener en cuenta cualquier secuencia posible de mezcla de pasos
de procesamiento de los procesos a sincronizar.
a

o
o
o

Para solucionar el problema de la alternancia, ahora usamos dos variables l´gicas (p0sc, p1sc) en lugar de
o
solo una. Cada variable vale true si el correspondiente proceso est´ en la secciń cr´
a
o
ıtica:
§
var p0sc : boolean := false ; { verdadero solo si proc. 0 en SC }
p1sc : boolean := false ; { verdadero solo si proc. 1 en SC }
¦
§
¤
§
process P0 ;
process P1 ;
begin
begin
while true do begin
while true do begin
p0sc := true ;
p1sc := true ;
{ seccion critica }
{ seccion critica }
p0sc := false ;
p1sc := false ;
{ resto seccion }
{ resto seccion }
end
end
end
end
¦
¥
¦

¤

¥
¤

¥

o
o

De nuevo, esta versiń no es correcta:
o

• Ahora s´ se cumple la propiedad de progreso en ejecuciń, ya que los procesos no tienen que entrar
ı
o
de forma necesariamente alterna, al usar dos variables independientes. Si un proceso quiere entrar,
podr´ hacerlo si el otro no est´ en SC.
a
a

• No se cumple, sin embargo, la exclusiń mutua, por motivos parecidos a la primera versiń, ya que se
o
o
pueden producir secuencias de acciones como esta:
◾ el proceso 0 accede al protocolo de entrada, ve p1sc con valor falso,

◾ el proceso 1 accede al protocolo de entrada, ve p0sc con valor falso,
◾ el proceso 0 pone p0sc a verdadero y entra en la secciń cr´
o
ıtica,
◾ el proceso 1 pone p1sc a verdadero y entra en la secciń cr´
o
ıtica.

o
o

Para solucionar el problema anterior se puede cambiar el orden de las dos sentencias del PE. Ahora las
variables l´gicas p0sc y p1sc estń a true cuando el correspondiente proceso est´ en SC, pero tambiń
o
a
a
e
cuando est´ intentando entrar (en el PE):
a

a

o

§
var p0sc : boolean := falso ; { verdadero solo si proc. 0 en PE o SC }
p1sc : boolean := falso ; { verdadero solo si proc. 1 en PE o SC }
¦
§
¤
§
process P0 ;
process P1 ;
begin
begin
while true do begin
while true do begin
p0sc := true ;
p1sc := true ;
{ seccion critica }
{ seccion critica }
p0sc := false ;
p1sc := false ;
{ resto seccion }
{ resto seccion }
end
end
end
end
¦
¥
¦

¤

¥
¤

¥

o
o

De nuevo, esta versiń no es correcta:
o

• Ahora s´ se cumple la exclusiń mutua. Es fćil ver que si un proceso est´ en SC, el otro no puede
ı
o
a
a
estarlo.
• Tambiń se permite el entrelazamiento con regiones no cr´
e
ıticas, ya que si un proceso accede al PE
cuando el otro no est´ en el PE ni en el SC, el primero lograr´ entrar a la SC.
a
a

• Sin embargo, no se cumple el progreso en la ejecuciń, ya que puede ocurrir interbloqueo. En este
o
caso en concreto, eso puede ocurrir si se produce una secuencia de acciones como esta:
◾ el proceso 0 accede al protocolo de entrada, pone p0sc a verdadero,

◾ el proceso 1 accede al protocolo de entrada, pone p1sc a verdadero,
◾ el proceso 0 ve p1sc a verdadero, y entra en el bucle de espera,

◾ el proceso 1 ve p0sc a verdadero, y entra en el bucle de espera.

o
o

Para solucionarlo, si un proceso ve que el otro quiere entrar, el primero pone su variable temporalmente a
false:

a

o

1
2
3
4
5
6
7
8
9

10
11
12
13
14

§
var p0sc : boolean := false ; { true solo si proc. 0 en PE o SC }
p1sc : boolean := false ; { true solo si proc. 1 en PE o SC }
¦
§
¤
§
process P0 ;
process P1 ;
begin
begin
while true do begin
while true do begin
p0sc := true ;
p1sc := true ;
while p1sc do begin
while p0sc do begin
p0sc := false ;
p1sc := false ;
{ espera durante un tiempo }
{ espera durante un tiempo }
p0sc := true ;
p1sc := true ;
end
end
{ seccion critica }
{ seccion critica }
p0sc := false ;
p1sc := false ;
{ resto seccion }
{ resto seccion }
end
end
end
end
¦
¥
¦

¤
¥
¤
1
2
3
4
5
6
7
8
9

10
11
12
13
14

¥

o
o

En este caso, se cumple exclusiń mutua pero, sin embargo, no es posible afirmar que es imposible que se
o
produzca interbloqueo en el PE. Por tanto, no se cumple la propiedad de progreso.

• La posibilidad de interbloqueo es pequeã, y depende de c´mo se seleccionen las duraciones de los
n
o
tiempos de la espera de cortes´ de c´mo se implemente dicha espera, y de la metodolog´ usada para
ıa,
o
ıa
asignar la CPU a los procesos o hebras a lo largo del tiempo.

• En particular, y a modo de ejemplo, el interbloqueo podr´ ocurrir si ocurre que:
ıa

◾ Ambos procesos comparten una CPU y la espera de cortes´ se implementa como una espera
ıa
ocupada.
◾ Los dos procesos acceden al bucle de las l´
ıneas 4-8 (ambas variables estń a verdadero).
a

3.2.2

◾ Sistem´ticamente, cuando un proceso est´ en la CPU y ha terminado de ejecutar la asignaciń
a
a
o
de la l´
ınea 7, la CPU se le asigna al otro.

Algoritmo de Dekker

Algoritmo de Dekker. Descripciń.
o

El algoritmo de Dekker debe su nombre a su inventor, es un algoritmo correcto (es decir, cumple las
propiedades m´
ınimas establecidas), y se puede interpretar como el resultado final del refinamiento sucesivo de Dijkstra:

• Al igual que en la versiń 5, cada proceso incorpora una espera de cortes´ durante la cual le cede al
o
ıa
otro la posibilidad de entrar en SC, cuando ambos coinciden en el PE.
• Para evitar interbloqueos, la espera de cortes´ solo la realiza uno de los dos procesos, de forma
ıa
alterna, mediante una variable de turno (parecido a la versiń 2).
o

a

o

• La variable de turno permite tambiń saber cuando acabar la espera de cortes´ que se implementa
e
ıa,
mediante un bucle (espera ocupada).

Algoritmo de Dekker. Pseudoc´digo.
o

1
2
3
4
5
6
7
8
9

10
11
12
13
14
15
16
17
18

§
var p0sc
: boolean := falso ; { true solo si proc.0 en PE o SC }
p1sc
turno0 : boolean := true ; { true ==> pr.0 no hace espera de cortesia }
¦
§
¤
§
process P0 ;
process P1 ;
begin
begin
while true do begin
while true do begin
p0sc := true ;
p1sc := true ;
while p1sc do begin
while p0sc do begin
if not turno0 then begin
if turno0 then begin
p0sc := false ;
p1sc := false ;
while not turno0 do
while turno0 do
begin end
begin end
p0sc := true ;
p1sc := true ;
end
end
end
end
{ seccion critica }
{ seccion critica }
turno0 := false ;
turno0 := true ;
p0sc := false ;
p1sc := false ;
{ resto seccion }
{ resto seccion }
end
end
end
end
¦
¥
¦

3.2.3

¤

¥
¤
1
2
3
4
5
6
7
8
9

10
11
12
13
14
15
16
17
18

¥

Algoritmo de Peterson

Algoritmo de Peterson. Descripciń.
o

Este algoritmo (que tambiń debe su nombre a su inventor), es otro algoritmo correcto para EM, que adem´s
e
a
es m´s simple que el algoritmo de Dekker.
a

• Al igual que el algoritmo de Dekker, usa dos variables l´gicas que expresan la presencia de cada
o
proceso en el PE o la SC, m´s una variable de turno que permite romper el interbloqueo en caso de
a
acceso simultńeo al PE.
a

• La asignaciń a la variable de turno se hace al inicio del PE en lugar de en el PS, con lo cual, en
o
caso de acceso simultńeo al PE, el segundo proceso en ejecutar la asignaciń (at´mica) al turno da
a
o
o
preferencia al otro (el primero en llegar).

• A diferencia del algoritmo de Dekker, el PE no usa dos bucles anidados, sino que unifica ambos en
uno solo.

Pseudoc´digo para 2 procesos.
o

El esquema del algoritmo queda como sigue:

a

o

1
2
3
4
5
6
7
8
9

10
11
12

§
var p0sc
p1sc
turno0 : boolean := true ; { true ==> pr.0 no hace espera de cortesia }
¦
§
¤
§
process P0 ;
process P1 ;
begin
begin
while true do begin
while true do begin
p0sc := true ;
p1sc := true ;
turno0 := false ;
turno0 := true ;
while p1sc and not turno0 do
while p0sc and turno0 do
begin end
begin end
{ seccion critica }
{ seccion critica }
p0sc := false ;
p1sc := false ;
{ resto seccion }
{ resto seccion }
end
end
end
end
¦
¥
¦

¤

¥
¤
1
2
3
4
5
6
7
8
9

10
11
12

¥

Demostraciń de exclusiń mutua. (1/2)
o
o

Supongamos que en un instante de tiempo t ambos procesos estń en SC, entonces:
a

(a) La ultima asignaciń (at´mica) a la variable turno0 (l´
´
o
o
ınea 5), previa a t, finaliz´ en un instante s (se
o
cumple s < t).

(b) En el intervalo de tiempo (s, t], ninguna variable compartida ha podido cambiar de valor, ya que en ese
intervalo ambos procesos estń en espera ocupada o en la secciń cr´
a
o
ıtica y no escriben esas variables.

(c) Durante el intervalo (s, t], las variables p0sc y p1sc valen verdadero, ya que cada proceso puso la
suya a verdadero antes de s, sin poder cambiarla durante (s, t].

Demostraciń de exclusiń mutua. (2/2)
o
o

de las premisas anteriores de deduce que:

(d) Si el proceso 0 ejecut´ el ultimo la l´
o
´
ınea 5 en el instante s, entonces no habr´ podido entrar en
ıa
SC entre s y t (la condiciń de espera del proc.0 se cumplir´ en el intervalo (s, t]), y por tanto en
o
ıa
s forzosamente fue el proceso 1 el ultimo que asign´ valor a turno0, luego turno0 vale verdadero
´
o
durante el intervalo (s, t].

(e) la condiciń anterior implica que el proceso 1 no estaba en SC en s, ni ha podido entrar a SC durante
o
(s, t] (ya que p0sc y turno0 vale verdadero), luego el proceso 1 no est´ en SC en t.
a

Vemos que se ha llegado a una contradicciń con la hip´tesis de partida, que por tanto debe ser falsa, luego
o
o
no puede existir ningń instante en el cual los dos procesos estń en SC, es decir, se cumple la exclusiń
u
e
o
m´tua.
u
Espera limitada

Supongamos que hay un proceso (p.ej. el 0) en espera ocupada en el PE, en un instante t, y veamos cuantas
veces m puede entrar a SC el proceso 1 antes de que el 0 logre hacerlo:

a

o

• El proceso 0 puede pasar a la SC antes que el 1, en ese caso m = 0.

• El proceso 1 puede pasar a la SC antes que el 0 (que continá en el bucle). En ese caso m = 1.
u

En cualquiera de los dos casos, el proceso 1 no puede despu´s llegar (o volver) a SC while el 0 continá en
e
u
el bucle, ya que para eso el proceso 1 deber´ pasar antes por la asignaciń de verdadero a turno0, y eso
ıa
o
provocar´ que (despu´s de un tiempo finito) forzosamente el proceso 0 entra en SC while el 1 continua en
ıa
e
su bucle.
Por tanto, la cota que requiere la propiedad es n = 1.

Progreso en la ejecuciń
o

Para asegurar el progreso es necesario asegurar

• Ausencia de interbloqueos en el PE: Esto es fćil de demostrar pues si suponemos que hay interbloqueo
a
de los dos procesos, eso significa que son indefinida y simultńeamente verdaderas las dos condiciones
a
de los bucles de espera, y eso implica que es verdad turno0 y no turno0, lo cual es absurdo.

• Independencia de procesos en RS: Si un proceso (p.ej. el 0) est´ en PE y el otro (el 1) est´ en
a
a
RS, entonces p1sc vale falso y el proceso 0 puede progresar a la SC independientemente del comportamiento del proceso 1 (que podr´ terminar o bloquearse estando en RS, sin impedir por ello el
ıa
progreso del proc.0). El mismo razonamiento puede hacerse al rev´s.
e

Luego es evidente que el algoritmo cumple la condiciń de progreso.
o

3.2.4

Algoritmo de Peterson para n procesos.

Algoritmo de Peterson para n procesos.

Peterson introdujo, junto con la versiń vista, una generalizaciń de su algoritmo para EM con n procesos.
o
o

• Cada proceso i (con 0 ≤ i < n) puede estar en uno de n + 1 estados posibles, numerados de −1 a n − 1:
◾ El estado −1 indica que el proceso est´ en RS.
a

◾ Los estados 0 al n − 2 indican que el proceso est´ en PE.
a
◾ El estado n − 1 indica que el proceso est´ en SC.
a

• Al ingresar en PE, el proceso pasa al estado 0. Durante el PE cada proceso pasa por todos los estados
0 ≤ j < n en orden, y en cada estado j (con j < n − 1) hace espera ocupada antes de pasar al j + 1.

• Las esperas estń diseãdas de forma que en cada estado j con j = 0, . . . , n − 1, puede haber n − j
a
n
procesos como mucho. Esto asegura la EM pues en el estado n − 1 (es decir, en SC) solo habr´ un
a
proceso como mucho.

Diagrama de estados.

Las transiciones en rojo suponen espera ocupada.
a

o

Protocolo de entrada
Max. n

Max. n-1

Max. n-2

Max. 3

Max. 2

0
0

1
1

2
2

n-3
n-3

n-2
n-2

Max. 1

-1
-1
Resto Sección

n-1
n-1
Sección Crítica

Variables compartidas

Las variables compartidas son dos vectores de enteros (de nombres estado y ultimo), que son escritos por
cada proceso justo cuando accede a un nuevo estado:

estado: la entrada i (con 0 ≤ i < n) contiene el estado del i-´simo proceso, es un valor entero entre −1 y
e
n − 1, ambos incluidos. Debe estar inicializado a −1.

ultimo: la entrada j (con 0 ≤ j < n) contiene el ´
ındice del ultimo proceso en ingresar en el estado j (es un
´
valor entero entre 0 y n − 1). Su valor inicial es indiferente (ya que los procesos siempre escriben en
una entrada antes de leerla).
Condici´n de espera en cada estado
o

Inicialmente, todos los procesos ingresan al estado 0 al inicio del PE. El proceso i puede pasar del estado
j al estado j + 1 tras hacer una espera ocupada, hasta que se d´ una cualquiera de estas dos condiciones:
e
(a) No hay otros procesos en el estado j ni en estados posteriores a j (incluyendo SC). En este caso el
proceso i es el m´s avanzado de todos los procesos en PE o SC (decimos que i es el proceso l´
a
ıder).
Esto equivale a:
∀ k ∈ {0, . . . , n − 1} t.q. k ≠ i : estado[k] < estado[i]

(b) Despu´s de que el proceso i ingresase al estado j, otros procesos tambi´n lo han hecho. Esto equivale
e
e
a:
i ≠ ultimo[j]

a

o
Pseudoc´digo.
o

§
{ Variables compartidas, valores iniciales y funciones }
var estado : array [0..n − 1] of integer ; { estado de cada proc. (inic. −1) }
ultimo : array [0..n − 2] of integer ; { ultimo proc. en cada estado del PE }
function lider( i : integer) : boolean; { ⇐⇒ ∀ k ≠ i : estado[k] < estado[i] }

¤

{ Procesos }
process P[ mi_numero : 0 .. n − 1 ] ;
begin
while true do begin
for mi_etapa := 0 to n − 2 do begin
estado[mi_numero] := mi_etapa ;
ultimo[mi_etapa] := mi_numero ;
while ultimo[mi_etapa]==mi_numero and not lider(mi_numero) do
begin end
end
estado[mi_numero] := n − 1 ;
{ seccion critica }
estado[mi_numero] := −1 ;
{ resto seccion }
end
¦

¥

La funciń l´gica lider.
o o

La funciń lider lee la variable compartida estado, y devuelve verdadero solo si el i-´simo proceso es el m´s
o
e
a
avanzado de todos los que estń en PE y SC:
a
§
function lider( i : integer ) : boolean ;
begin
for k := 0 to n − 1 do
if i ≠ k and estado[i] ≤ estado[k] then
return false ;
return true ;
end
¦

3.3

3.3.1

¤

¥

Soluciones hardware con espera ocupada (cerrojos) para E.M.
Introducciń
o

Introducciń
o

Los cerrojos constituyen una soluciń hardware basada en espera ocupada que puede usarse en procesos
o
concurrentes con memoria compartida para solucionar el problema de la exclusiń mutua.
o

• La espera ocupada constituye un bucle que se ejecuta hasta que ningń otro proceso est´ ejecutando
u
e
instrucciones de la secciń cr´
o
ıtica

• Existe un valor l´gico en una posiciń de memoria compartida (llamado cerrojo) que indica si algń
o
o
u
proceso est´ en la secciń cr´
a
o
ıtica o no.

a

o

• En el protocolo de salida se actualiza el cerrojo de forma que se refleje que la SC ha quedado libre

Veremos una soluciń elemental que sin embargo es incorrecta e ilustra la necesidad de instrucciones
o
hardware espec´
ıficas (u otras soluciones m´s elaboradas).
a
Una posible soluciń elemental
o

Vemos un esquema para procesos que ejecutan SC y RS repetidamente:

§
var sc_ocupada : boolean := false ; { cerrojo: verdadero solo si SC ocupada }
{ procesos }
process P[ i : 1 .. n ];
begin
while true do begin
while sc_ocupada do begin end
sc_ocupada := true ;
{ seccion critica }
sc_ocupada := false ;
{ resto seccion }
end
end
¦

¤

¥

Errores de la soluciń simple
o

La soluciń anterior no es correcta, ya que no garantiza exclusiń mutua al existir secuencias de mezclado
o
o
de instrucciones que permiten a m´s de un proceso ejecutar la SC a la vez:
a
• La situaciń se da si n procesos acceden al protocolo de entrada y todos ellos leen el valor del cerrojo
o
a false (ninguno lo escribe antes de que otro lo lea).
• Todos los procesos registran que la SC est´ libre, y todos acceden a ella.
a

• El problema es parecido al que ya vimos de acceso simultńeo a una variable en memoria compartida:
a
la lectura y posterior escritura del cerrojo se hace en varias sentencias distintas que se entremezclan.

una soluciń es usar instrucciones m´quina at´micas (indivisibles) para acceso a la zona de memoria donde
o
a
o
se aloja el cerrojo. Veremos dos de ellas: LeerAsignar (TestAndSet) e Intercambia (Swap).

3.3.2

La instrucciń LeerAsignar.
o

La instrucciń LeerAsignar.
o

Es una instrucciń m´quina disponible en el repertorio de algunos procesadores.
o
a

• admite como argumento la direcciń de memoria de la variable l´gica que actua como cerrojo.
o
o
• se invoca como una funciń desde LLPP de alto nivel, y ejecuta estas acciones:
o
1. lee el valor anterior del cerrojo

a

o
2. pone el cerrojo a verdadero

3. devuelve el valor anterior del cerrojo

• al ser una unica instrucciń m´quina su ejecuciń no puede entremezclarse con ninguna otra instrucciń
´
o a
o
o
ejecutada en el mismo procesador

• bloquea el bus del sistema y la memoria donde est´ el cerrojo de forma que ninguna otra instrucciń
a
o
similar de otro procesador puede entremezclarse con ella.

Protocolos de entrada y salida con LeerAsignar

La forma adecuada de usar LeerAsignar es la que se indica en este esquema:

§
var sc_ocupada : boolean := false ; { true solo si la SC esta ocupada }
{ procesos }
process P[ i : 1 .. n ];
begin
while true do begin
while LeerAsignar( sc_ocupada ) do begin end
{ seccion critica }
sc_ocupada := false ;
{ resto seccion }
end
end
¦

¤

¥

cuando hay m´s de un proceso intentando entrar en SC (estando SC libre), solo uno de ellos (el primero en
a
ejecutar LeerAsignar) ve el cerrojo (sc ocupada) a falso, lo pone a verdadero y logra entrar a SC.

3.3.3

La instrucciń Intercambia.
o

La instrucciń Intercambia.
o

Constituye otra instrucciń hardware que, al igual que LeerAsignar, se ejecuta de forma at´mica en entornos
o
o
con varios procesos ejecutńdose en uno o varios procesadores compartiendo memoria.
a
• actua sobre un cerrojo (un valor l´gico) en memoria compartida
o
• admite dos argumentos:

◾ la direcciń de memoria del cerrojo (variable global en memoria compartida)
o

◾ la direcciń de memoria de otra variable l´gica (no necesariamente compartida, t´
o
o
ıpicamente es
una variable local del proceso que llama a Intercambia)

o
o
• el efecto de la instrucciń es intercambiar los dos valores l´gicos almacenados en las posiciones de
memoria indicadas

• se invoca como un procedimiento

a

Sis Concur Distrib

Recomendados

Recomendados

Más contenido relacionado

La actualidad más candente

La actualidad más candente (15)

Similar a Sis Concur Distrib

Similar a Sis Concur Distrib (20)

Más de Marlene Vásquez

Más de Marlene Vásquez (6)

Sis Concur Distrib