Universidad Nacional de Educacion a Distancia

Gua Didactica
Programacion Concurrente
(Ingeniera Tecnica Informatica de Sistemas)

Equipo docente:
David Fernandez Amoros

c
2008
David Fernandez Amoros. Todos los derechos reservados.


INDICE

Indice
1. Informacion general

1.1. Presentacion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

1.2. Introduccion a la asignatura . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

2. Presentacion de los contenidos

2.1. Objetivos generales . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

7
8

3. Requisitos previos

4. Materiales

5. Orientaciones generales para el estudio

10

6. Distribucion del tiempo de estudio

12

7. Evaluacion

12

7.1. Pruebas de evaluacion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

12

7.2. Criterios de calificacion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

13

8. Programa

13

8.1. Bloque tematico 1: Introduccion y conceptos basicos . . . . . . . . . . . . . . . . . .

13

8.1.1. Objetivos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

14

8.1.2. Orientaciones especficas de los temas . . . . . . . . . . . . . . . . . . . . . .

15

8.2. Bloque tematico 2: Herramientas para manejar la concurrencia . . . . . . . . . . . . .

17

8.2.1. Objetivos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

18

8.3. Orientaciones especficas de los temas . . . . . . . . . . . . . . . . . . . . . . . . . .

19


INDICE

8.4. Bloque tematico 3: Problemas de aplicacion . . . . . . . . . . . . . . . . . . . . . . .

23

8.4.1. Objetivos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

23

8.5. Orientaciones sobre los contenidos . . . . . . . . . . . . . . . . . . . . . . . . . . . .

23

9. Actividades

24

1 Informacion general

1.
1.1.

Informacion general
Presentacion

Esta gua pretende orientar al alumno en la planificacion y el estudio de la asignatura.

Se recomienda leer la gua en su totalidad al principio del cuatrimestre para tener una vision
de conjunto de la dinamica del curso. Esta informacion se complementa con el enunciado
de la practica obligatoria, las preguntas frecuentes y los problemas de examen disponibles
en el curso virtual, de forma que el estudiante pueda planificar desde el principio el estudio
y realizacion de la practica para aprovechar el tiempo al maximo y no perder los plazos de
entrega.

1.2.

Introduccion a la asignatura

El a mbito de conocimiento de esta asignatura es el de la programacion en computacion

paralela o distribuida. La programacion concurrente (en adelante PC) anade una capa suplementaria de complejidad respecto de la secuencial, por cuanto que es una extension de esta, en
el sentido de que un programa concurrente esta compuesto por varios programas secuenciales
que pueden ejecutarse simultaneamente, compartiendo el acceso a unos recursos compartidos,
con vistas a la consecucion de un objetivo comun. De la comparticion de recursos surge la necesidad de arbitrar mecanismos adecuados para permitir el acceso, ya sea para leer, ya sea para
modificar el recurso compartido, de manera que se garantice que la informacion que proporciona en cualquier momento sea coherente. Esta necesidad de coherencia, unida a la articulacion
de los programas individuales que constituyen el programa concurrente en un calculo comun,
lleva a la cuestion de la sincronizacion entre los programas. Se estudiaran diferentes herramientas propuestas historicamente para manejar la ejecucion simultanea de programas junto
con esquemas algortmicos desarrollados para el tratamiento de situaciones comunes en PC.
Las tecnicas aprendidas se pondran en aplicacion en un trabajo practico de caracter obligatorio
en el que se desarrollara un programa concurrente que sirva de modelo a una situacion descrita
en el enunciado del mismo.
Los contenidos de esta asignatura se encuentran incluidos en otros planes de estudio dentro
las asignaturas de sistemas operativos o de sistemas en tiempo real, si bien comunmente en dichas materias la problematica especfica de la PC no se encuentra desarrollada, ni en extension
ni en profundidad al nivel en que se hace en esta.
En el marco docente que desarrolla el actual plan de estudios, PC es una asignatura optativa de tercer curso de la titulacion de Ingeniera Tecnica en Informatica de Sistemas, si bien
esta disponible como asignatura de libre configuracion y de libre eleccion dentro de la Escuela
5

1.2

Introduccion a la asignatura

Superior de Ingeniera Informatica de la UNED. Se imparte durante el primer cuatrimestre del

tercer curso.
La evaluacion de la asignatura incluye un trabajo obligatorio de ndole practica por imperativo del reglamento del departamento LSI. En la practica obligatoria de la asignatura y en
el examen solo se exigira la codificacion de los programas en pseudocodigo, sin embargo, se
recomienda encarecidamente que el programa de la practica y los ejercicios se codifiquen y
prueben con un lenguaje de programacion concreto. En la bibliografa de la asignatura se hace
hincapie principalmente en los lenguajes PASCAL-FC, Java y en menor medida Ada, aunque
el lenguaje elegido no es importante siempre que se utilicen las herramientas de sincronizacion
pertenecientes al temario, aunque sea de forma simulada. Cada uno de ellos tiene sus ventajas
e inconvenientes:
PASCAL-FC es el decano de los lenguajes de programacion concurrente, no tanto por
su antiguedad sino por el hecho de no haber sido actualizado desde hace decadas. Con
implementaciones para DOS, Windows y Linux, sus ventajas son la simplicidad del
lenguaje, que tiene las mnimas caractersticas de programacion, y la variedad de herramientas de concurrencia que soporta. Existen editores especficos para Windows e
incluso un plugin para el entorno de programacion multiplataforma ECLIPSE. Entre las
desventajas, se podra mencionar que tiene un cuarto de siglo con todo lo que ello conlleva, restricciones absurdas hoy en da respecto al numero maximo de procesos y de
monitores, falta de tipos de datos basicos como seran las cadenas de caracteres (solo
existe el tipo caracter) y hasta maximo numero de instrucciones ejecutadas. Un programa que ejecute 200000 instrucciones es abortado y automaticamente sospechoso de
livelock. Tampoco hay manera de definir una funcion dentro de un monitor, aunque teoricamente es posible. Estas limitaciones pueden ser severas incluso a la hora de realizar la
practica de la asignatura.
Java es un lenguaje de proposito general, multiplataforma y constantemente modernizado. Existen editores y documentacion de todo tipo. Si bien las limitaciones de sus
implementaciones en diversas plataformas y el hecho de ser muy a menudo interpretado
pueden afectar negativamente sus posibilidades reales, sus limitaciones estan a anos luz
de las de PASCAL-FC. Aunque sus primitivas de sincronizacion inicialmente no tenan
nada que ver con las estudiadas en la asignatura, hoy en da la situacion ha mejorado
considerablemente. El punto mas debil de Java para esta asignatura es que requiere el
aprendizaje de un lenguaje complejo, mientras que PASCAL-FC es casi inmediato.
Ada es un lenguaje de proposito general, multiplataforma. Se considera un lenguaje especializado. Entre sus principios de diseno se encuentran la eficiencia y la concurrencia,
cosa que no puede decirse a la vez de los dos lenguajes anteriormente mencionados. Sus
primitivas de concurrencia apenas coinciden con las del temario de la asignatura, excepto
en el caso de la invocacion remota (tambien conocida como cita de Ada o rendez-vous).
Las desventajas son claras: se trata de un lenguaje de una extraordinaria complejidad,
6

2 Presentacion de los contenidos

con una curva de aprendizaje alta, poca variedad de compiladores y pocas posibilidades
de uso fuera del departamento de defensa de los Estados Unidos de America, donde fue
desarrollado originalmente.
La PC se ha restringido tradicionalmente a unas a reas de aplicacion muy concretas, pero
de una importancia incuestionable:
Sistemas empotrados: Sistemas sencillos, habitualmente sin sistema operativo, en un
hardware especfico, en los que unos programas que se ejecutan concurrentemente leen
unos sensores y toman decisiones como activar o desactivar otros componentes electronicos. Un ejemplo sencillo sera un termostato.
Sistemas operativos: En un sistema operativo multiprogramado lo normal es que haya
varios procesos ejecutandose en paralelo (ya se trate de paralelismo real o simulado). Es
necesario sincronizar dichos procesos para que los programas del sistema y los de los
usuarios puedan compartir los recursos de la maquina. Un caso particular pero especialmente relevante sera el de los sistemas operativos distribuidos.
Sistemas de Gestion de Bases de Datos: Los SS.GG.BB.DD tienen entre sus objetivos
de diseno el proporcionar un acceso eficiente a los datos manteniendo la consistencia
de los mismos. Para permitir el acceso simultaneo de varios programas y mantener al
mismo tiempo la consistencia de los datos entre las transacciones, se aplican tecnicas de
PC.
Computacion en malla: Se utilizan muchos ordenadores, conectados en red, para realizar
un calculo entre todos. El ejemplo mas conocido quiza sea el del proyecto SETI@Home,
en el que ordenadores situados a lo largo de todo el planeta buscan coordinadamente
indicios de vida extraterrestre.
Pese a sus comienzos especializados, en la informatica de consumo se ha popularizado en
los u ltimos tiempos el uso de sistemas multiprocesador. En estas CPUs con dos, tres o cuatro
nucleos, las ventajas de la PC son incluso mas claras que en un entorno monoprocesador, lo
que hace previsible un aumento de la demanda de profesionales con conocimientos solidos en
este campo.

2.

Presentacion de los contenidos

Tras presentar algunos conceptos fundamentales de la PC, el foco se desplaza al uso de

tecnicas concretas de PC. En particular, se hace un recorrido por algunas de las herramientas
7

2.1

Objetivos generales

de sincronizacion de procesos concurrentes en el a mbito de la memoria compartida: semaforos, regiones crticas, regiones crticas condicionales y monitores. En los temas siguientes se
introducen los conceptos asociados al paso de mensajes y algunas de las herramientas correspondientes, en concreto buzones e invocacion remota. En todos los temas referentes a herramientas concretas se estudian soluciones a los dos problemas-tipo de la PC, que pueden verse
como esquemas algortmicos: El problema de los lectores y escritores y el problema de los
productores y consumidores. Otro aspecto transversal es el de la equivalencia de las distintas
herramientas; el comportamiento de cualquier herramienta puede simularse mediante otra, a
pesar de lo cual todas ellas poseen caractersticas distintivas que hacen que unas sean mas
apropiadas que otras frente a un problema concreto.

2.1.

Objetivos generales
Presentar los problemas derivados de la ejecucion simultanea de tareas
Introducir esquemas algortmicos generales aplicables a numerosos problemas
Adiestrar al estudiante en el empleo de diversas herramientas de sincronizacion de procesos
Desarrollar la capacidad de analisis y diseno de soluciones a un problema de simulacion
mediante el uso de tecnicas aprendidas en la asignatura

3.

Requisitos previos

En un modelo de capas o niveles de abstraccion, la PC se encontrara en un nivel superior

al de la programacion convencional. Dado que es el sistema el que proporciona la concurrencia, lo que corresponde al programador es administrar dicha concurrencia, de forma que las
diferentes partes de un programa concurrente calculen juntas un resultado al tiempo que se
mantiene la consistencia de los datos. Las tecnicas de programacion secuencial se dan por supuestas. Sin embargo, dicho esto hay que matizar que el e nfasis de la materia se centra en los
mecanismos de sincronizacion de procesos, por lo que no se presta demasiada atencion a los
aspectos formales y metodologicos de la programacion. Por tal motivo, los u nicos requisitos
previos seran un conocimiento solido de los contenidos correspondientes a la asignatura Programacion I, de primer curso. Sera u til, aunque no imprescindible, que el alumno tuviera una
cierta familiaridad con con los contenidos de la asignatura Estructuras de Datos y Algoritmos,
de segundo curso, especialmente en lo referido a tipos abstractos de datos. Por u ltimo, el contenido de la asignatura se relaciona con el de Sistemas Operativos I, de segundo curso, por lo
que respecta a la relacion de los estados de un programa concurrente en relacion con el sistema
operativo, por lo que una cierta familiaridad con los conceptos fundamentales de este tambien
8

4 Materiales

resulta conveniente. Con esta asignatura hay un cierto grado de solapamiento, puesto que en
ella se dedica un tema de estudio a la PC. Evidentemente, el enfoque de aquella resulta mas
ligero, por lo que su estudio podra proporcionar una introduccion a los temas desarrollados
en esta asignatura.
Dejando de lado algunas cuestiones de estilo de programacion, los problemas habituales
de la asignatura no suelen estar relacionados con un aprendizaje deficiente de asignaturas anteriores, por lo que no se considera necesario reforzar capacidades anteriores. Se recomienda
que se implementen y se prueben los problemas de los ejercicios y de la practica obligatoria,
por lo que se asume cierta destreza en la instalacion y utilizacion de entornos de compilacion
y desarrollo.

4.

Materiales
Los contenidos de la asignatura se desarrollan completamente en el texto base:
Programacion Concurrente, Palma et al., Editorial Thomson, 2003.

En el texto base se discuten los conceptos fundamentales de la asignatura, as como numerosos ejemplos de aplicacion y ejercicios resueltos. Tambien se proponen problemas por
resolver, de modo que resulta un texto adecuado para el aprendizaje a distancia. Es cierto que
en algunas de sus consideraciones practicas, como la implementacion en Java de algunas de
las tecnicas, ya esta obsoleto debido al rapido avance de la tecnica, pero afortunadamente, la
presentacion de los conceptos y tecnicas es completamente actual.
El alumno encontrara en el curso virtual materiales adicionales para el seguimiento de la
asignatura. Entre ellos, enunciados de examenes anteriores, examenes resueltos, demostraciones de simulaciones realizadas aplicando las tecnicas objeto de estudio, as como compiladores
y documentacion sobre lenguajes de programacion con posibilidades de concurrencia. Como
resultado de un seguimiento de las dificultades de los alumnos en relacion con la asignatura, se
ha realizado un lista de preguntas frecuentes para optimizar el proceso de aprendizaje y evitar
la sobrecarga del equipo docente, que redunda en unos tiempos de respuesta mas largos a las
dudas del alumnado. Una parte del mismo material se ha incluido en el DVD de la Escuela Superior de Ingeniera Informatica, para aquellos alumnos a los que les resulte mas conveniente
este medio.
La bibliografa complementaria consta de las siguientes obras:
Programacion concurrente. 2a edicion corregida, Perez Martnez, J. E., Madrid, Editorial Rueda, 1990.
9

5 Orientaciones generales para el estudio

Durante algunos anos, esta obra fue el texto base de la asignatura. Esta obra peca quizas
de un enfoque un tanto teorico para una disciplina aplicada como es la programacion,
pero supone un excelente contrapunto al estudio del texto base, ya que, a menudo, la
bibliografa basica menciona rapidamente aspectos vitales, como pueden ser la necesidad absoluta de la exclusion mutua en los accesos no compatibles, o las causas de los
interbloqueos y las polticas para evitarlo, pero no los subraya. Este libro profundiza
teoricamente y ejemplifica los conceptos. El analisis de los puntos fuertes y debiles de
cada una estas obras en relacion con la otra permite obtener una vision de conjunto de
la disciplina mucho mas completa, y altamente recomendable, que la proporcionada por
cada una de ellas individualmente.
Principles of Concurrent and Distributed Programming. 2o Edicion, Ben-Ari, M., AddisonWesley, 2006
Mordechai Ben-Ari es una de las figuras de referencia de la PC actual. Este matematico
israel, premiado por sus contribuciones a la ensenanza de la informatica ha sido un
activo colaborador en el desarrollo del lenguaje Ada. Una prueba de lo influyente de
esta obra, desde la primera edicion en 1990, la da la mera comparacion de su ndice con
el de las dos obras citadas anteriormente.
Ada for Software Engineers, Ben-Ari, M., John Wiley & Sons, 1998.
Este libro proporciona una introduccion al lenguaje Ada de la mano de unos los expertos en el campo de la computacion distribuida. Las caractersticas concurrentes forman
parte de los principios de diseno de Ada, hecho este que lo diferencia de la mayora de
los lenguajes de programacion con posibilidades de concurrencia, en las que estas no
suponen mas que un anadido a posteriori.

5.

Orientaciones generales para el estudio

Una primera lectura rapida del libro puede proporcionar una adecuada vision de conjunto
de los problemas que se van a tratar. En esta primera lectura se pueden ignorar los apartados
relativos a la puesta en practica de la teora en los diversos lenguajes considerados (PASCALFC, Java y Ada). La primera unidad didactica se corresponde con parte de los tres primeros
captulos del texto base, que pueden considerarse como una introduccion extendida a los conceptos fundamentales de la PC. La informacion relevante de estos captulos puede ser extrada
en la primera lectura, de forma que no se precise una relectura mas adelante.
La segunda unidad didactica trata las diversas herramientas para manejar la concurrencia.
La tercera consiste en las soluciones a problemas de aplicacion. Estas dos unidades estan
entremezcladas en el texto. Esta parte del libro puede estudiarse siguiendo el esquema de
distribucion del tiempo de la siguiente seccion, o bien leerse en orden ya que, despues de
10

5 Orientaciones generales para el estudio

presentar una herramienta para controlar la concurrencia, se pasa a implementar la solucion

a los problemas-tipo utilizando dicha herramienta. Este enfoque ofrece la ventaja de que el
estudiante se familiariza rapidamente con los problemas que se resuelven y pronto solo le
resulta novedosa la solucion que emplea la herramienta especfica considerada.
Estas dos unidades didacticas se merecen una segunda lectura mas interpretativa. En primer
lugar, para ser capaz de programar correctamente una solucion a un problema concreto, es
necesario dominar los detalles de cada herramienta. Cada herramienta consta de una sintaxis,
semantica y conjunto de estados especfico para los procesos (con sus diversos circuitos de
colas de espera asociadas) que deben conocerse y manejarse con soltura. Un ejercicio muy
u til para aclarar dudas y retener conceptos es implementar las primitivas de una herramienta
utilizando otra. Este ejercicio tiene ademas la ventaja de que a menudo un lenguaje de PC no
soporta de forma nativa mas que unas pocas herramientas de sincronizacion, de forma que si
queremos usar otras deberemos primero simularlas mediante esas herramientas nativas. Otro
aspecto sobre el que conviene reflexionar a medida que se estudia el texto base, es el comparar
unas herramientas de sincronizacion con otras. No hay herramientas mejores que otras, puesto
que a nivel teorico todas son equivalentes, pero s se pueden clasificar segun sean de alto o
bajo nivel, sirvan para cualquier arquitectura, caso de las de paso de mensajes, o solo sean
aptas para entornos de memoria compartida, etc. . . En una situacion concreta, es muy posible
que haya unas herramientas mas adecuadas que otras, por ello hay que intentar ser consciente
de las diferencias entre ellas.
En cualquier caso, tras esa primera lectura es cuando se puede comenzar a trabajar la
practica obligatoria de la asignatura, aunque este trabajo se limite a poco mas que el analisis
del enunciado. Es por desgracia frecuente que un alumno, presionado por los plazos de entrega,
decida enfocar la asignatura con el metodo de tirarse a la piscina, o sea, empezar a programar
sin leerse el libro apenas, o sin haberlo ledo en absoluto. Habida cuenta de la abundancia de
material sobre programacion disponible en la Red, esta posibilidad supone una tentacion, sin
embargo dicho enfoque suele dejar unas lagunas que terminan suponiendo un grave lastre, que
es detectado por el equipo docente mas tarde de lo que sera deseable (tpicamente despues de
la primera entrega de la practica, lo que lleva a hacer una segunda entrega no deseada previamente por ninguna de las partes). Una aproximacion mas interesante puede ser la siguiente;
despues de hacer una lectura rapida de los temas del libro correspondientes al temario, se
puede analizar el enunciado de la practica y tomar una decision sobre la herramienta que se
va a utilizar en la practica obligatoria. Resulta vital analizar si el problema de la practica se
puede asimilar de alguna manera a algun problema-tipo. Como solo hay dos problemas-tipo,
la comprobacion no debera ser difcil. A continuacion, se puede estudiar detenidamente dicha herramienta, de modo que el trabajo sobre la practica pueda ser llevado paralelamente al
estudio del resto del temario.

11

6 Distribucion del tiempo de estudio

Unidad
Didactica
I

II

III

Temario

Horas de estudio

Teora Practica
Tema 1. Introduccion
2
Tema 2. Procesos vs. hilos
1
Tema 3. Exclusion mutua
2
Tema 4. Semaforos
3
Tema 5. Regiones Crticas Condicionales
2
Tema 6. Monitores
3
20
Tema 7. Buzones
3
Tema 8. Invocacion Remota
3
Tema 9. Equivalencia de Herramientas
3
Tema 10. Problemas de aplicacion
5
Figura 1: Temporizacion de la asignatura

6.

Distribucion del tiempo de estudio

Programacion concurrente es una asignatura cuatrimestral de cinco creditos: tres de teora

y dos de practica. Un credito equivale a diez horas de estudio, lo que resulta en cincuenta
horas de estudio. En la figura 6 se puede ver la temporizacion propuesta. Se propone un plan
de trabajo de unas dos horas y media de estudio teorico por semana. A partir de la tercera
semana, el estudio teorico se combina con la realizacion de la practica a razon de unas dos
horas por semana.

7.
7.1.

Evaluacion
Pruebas de evaluacion

La calificacion de la asignatura tendra en cuenta la calificacion de la practica obligatoria

de la asignatura y la calificacion de la prueba presencial. Para aprobar la asignatura, tanto la
practica como la prueba presencial deben estar aprobadas. La nota de la practica en una convocatoria se guarda para las siguientes del mismo curso. La practica solo tiene dos calificaciones:
apto y no apto. La superacion de la practica no implica aumento de la calificacion final, aunque en algunos casos excepcionales puede aumentar o disminuir ligeramente la calificacion
total. En el SIRA solo quedara reflejada la calificacion global, aunque en el curso virtual aparecera detallada la calificacion de la practica. No hay pruebas de evaluacion a distancia. La
practica de la asignatura no comporta la asistencia a sesiones presenciales. Los alumnos sin
12

7.2

Criterios de calificacion

tutor pueden consultar sus dudas sobre la practica en el foro correspondiente del curso virtual.
La no superacion de la practica en una convocatoria conlleva el suspenso en dicha convocatoria, por lo que si las nota de la practica esta disponible antes de los examenes y no ha sido
superada, no tiene sentido realizar la prueba presencial.

7.2.

Criterios de calificacion

En la prueba presencial se pedira el desarrollo de un programa concurrente similar al de la

practica. El programa del examen requiere la puesta en practica de los conocimientos adquiridos durante el estudio de la asignatura, pero habitualmente no suele consistir en una aplicacion
inmediata de un concepto teorico o problema-tipo. Es frecuente que se mezclen los problemastipo de alguna forma, e incluso que sea necesario generalizar y combinar los problemas-tipo
de forma no trivial y con cierto grado de creatividad. Tambien ocurre con frecuencia que el
programa del examen no responda claramente a un esquema algortmico. En funcion de la
complejidad del mismo, puede haber tambien cuestiones teorico-practicas. Los criterios de
evaluacion de la practica y del problema de la prueba presencial son similares.

8.

Programa
La asignatura se articula a traves de tres bloques tematicos:
Bloque tematico 1: Introduccion y conceptos basicos
Bloque tematico 2: Herramientas para manejar la concurrencia
Bloque tematico 3: Problemas de aplicacion
Estos bloque tematicos se describen en detalle a continuacion.

8.1.

Bloque tematico 1: Introduccion y conceptos basicos

Este bloque tematico presenta las particularidades suplementarias de la PC respecto a la

programacion secuencial. Se motiva la necesidad y conveniencia de la PC, y se realizan algunas
consideraciones sencillas sobre su implementacion a bajo nivel. Tambien se introducen los
conceptos de proceso e hilo, lo que permite profundizar en la problematica de la PC en general
y de la exclusion mutua en particular.
13

8.1

Bloque tematico 1: Introduccion y conceptos basicos

8.1.1.

Objetivos

Tras estudiar este bloque tematico, el estudiante debera haber comprendido las diferencias
esenciales entre la PC y la secuencial, as como ser consciente de las diferentes arquitecturas
fsicas de los sistemas en los que puede emplearse la PC. Una de estas caractersticas anadidas
es el concepto de estado del de un proceso. En programacion clasica los estados de un programa son limitados; el sistema operativo carga y lanza el programa, que se ejecuta hasta su
finalizacion. En PC cada proceso o hilo es un correlato del programa secuencial, pero puede
encontrarse en un conjunto de estados mayor. Estos estados adicionales se derivan del hecho
de que los procesos tienen que sincronizarse entre ellos, lo que a menudo significa que algunos
de ellos deben esperar a que otros hayan realizado parte de su tarea. El otro gran problema de
la PC es el de la exclusion mutua. Dos procesos no deben acceder concurrente a un mismo
recurso (como una variable compartida o un periferico) de forma no compatible. Una vez que
un programa concurrente se sincroniza en sus diversas partes correctamente y preserva la exclusion mutua a los recursos no compartibles, se puede considerar correcto. Sin embargo, hay
otros problemas graves que pueden hacer poco aceptable un programa concurrente correcto.
Algunos de estos problemas son la inanicion, el establecimiento de turnos, la baja concurrencia, la espera activa y el interbloqueo. El interbloqueo se trata extensamente en el libro de
Perez Garca, donde se discuten tecnicas diferenciadas para detectarlo, evitarlo y prevenirlo.
El estudiante debera ser capaz de identificar estas situaciones para poder evitarlas empleando las herramientas descritas en el segundo bloque tematico.

Temas
1. INTRODUCCION
Conceptos fundamentales de la programacion concurrente
Concepto de programacion concurrente
Beneficios de la programacion concurrente
Concurrencia y arquitecturas hardware
Especificacion de ejecucion concurrente
Caractersticas de los sistemas concurrentes
Problemas inherentes a la programacion concurrente
2. PROCESOS vs. HILOS
Procesos
Hilos
14

8.1

Bloque tematico 1: Introduccion y conceptos basicos

Grafos de estados de un proceso / hilo

Ciclo de vida de un proceso / hilo
Grafos y diagramas de precedencia
3. EXCLUSION MUTUA.
Introduccion al problema
Tipos de sincronizacion y su solucion
Soluciones con espera ocupada
(excepto algoritmos de Eisenberg-McGuire y Algoritmo de Lamport)

8.1.2.

Orientaciones especficas de los temas

Tema 1 Introduccion
La introduccion a la Programacion Concurrente, como toda la asignatura, puede estudiarse por el libro de Palma et al., en adelante texto base. La secciones que proporcionan
una introduccion a los conceptos fundamentales de la PC, son la 1.1 (introduccion) junto
con la 1.2 (concepto de PC), 1.3 (beneficios de la PC), 1.4 (concurrencia e arquitecturas
hardware), 1.5 (especificacion de ejecucion concurrente), 1.6 (caractersticas de los sistemas concurrentes), 1.7 (problemas inherentes a la PC) y 1.8 (correccion de programas
concurrentes).
El estudio de este tema debe proporcionar al estudiante una vision de conjunto de la problematica de la PC y de algunas caractersticas diferenciales respecto a la programacion
secuencial. En particular, las diferentes arquitecturas hardware posibles, el concepto de
traza de ejecucion y el indeterminismo tienen una influencia determinante en PC. Junto a
los beneficios presentados de la PC, hay que ser consciente de los problemas asociados,
que pueden ser de diversos tipos.
Lo mas importante que hay retener de este tema es que un programa concurrente no
debe hacer ninguna suposicion sobre la arquitectura del sistema en el que se ejecuta. Un
programa concurrente se puede ejecutar en un entorno monoprocesador multiprogramado, en el cual no se produce concurrencia real sino que se simula. Sin embargo, tambien
es frecuente (quiza lo mas frecuente en nuestros das) que la maquina cuente con varios
procesadores, de manera que, de hecho, haya varios procesos ejecutandose en el mismo
momento.
El programador, en principio, solo debera preocuparse de saber si la arquitectura admite
memoria compartida o, por el contrario, se trata de un sistema distribuido. En el primer
caso, todas las primitivas de sincronizacion pueden ser consideradas, en el segundo, solo
las herramientas basadas en paso de mensaje son admisibles.

15

8.1

Bloque tematico 1: Introduccion y conceptos basicos

Las condiciones de Bernstein pueden ayudar a determinar que es lo que se puede ejecutar
de forma concurrente y lo que no, aunque como resumen, se puede decir que cualquier
numero de procesos puede leer de un determinado recurso de forma concurrente. Sin
embargo, el que haya un proceso escribiendo en el recurso lo hace incompatible tanto
con otros procesos escritores como con procesos lectores.
Esta cuestion esta estrechamente relacionada con la del indeterminismo. Si bien el indeterminismo en programacion no es negativo per se (imaginemos, por ejemplo, un
generador de numeros pseudoaleatorios) un programa concurrente querra en la mayora
de los casos mantener cierta coherencia en los datos. En el ejemplo de la subseccion
1.6.2, vemos como un acceso no controlado a una variable hace que el valor de la misma
sea impredecible. Pensemos ahora en un programa que controle el funcionamiento de
una red de cajeros automaticos. Podemos querer cierta concurrencia, pero seguramente
no queremos que se cree ni se destruya dinero en el proceso. La forma correcta de enfocar el problema tiene que garantizar el acceso en exclusion mutua a las cuentas en los
accesos incompatibles con las condiciones de Bernstein.
Esta cuestion es lo suficiente importante como para repetirla una vez mas: Una variable
compartida debe ser accedida siempre en exclusion mutua, salvo en los casos en los que
se asegure que no hay ningun otro proceso intentando modificar dicha variable al mismo
tiempo. En la practica, esto significa que las variables compartidas deben accedidas (ya
sea para leer o para modificar sus valores) en exclusion mutua, salvo que se desarrolle
un esquema de lectores y escritores, objeto de estudio del tercer bloque tematico.
Tema 2 Procesos vs. hilos
En el segundo captulo del libro de Palma et al. se profundiza en las diferencias entre
procesos e hilos en las secciones 2.1 (procesos) y 2.3 (hilos) Los conceptos mas importantes de este tema son:
La distincion entre programa, proceso e hilo.
El concepto de estados de un proceso o hilo y su ciclo de vida.
Los grafos y diagramas de precedencia.
Los problemas de la PC, en particular la exclusion mutua y la condicion de sincronizacion.
Excepcion hecha de las dos secciones mencionadas, el resto de este captulo del libro no
esta muy relacionado con el contenido de la asignatura. Contiene multitud de detalles
tecnicos que son a la vez demasiado avanzados y relativamente irrelevantes a la hora de
comprender conceptualmente la asignatura. En algun caso la informacion all expuesta
puede servir para el estudiante a la hora de codificar y ejecutar sus programas concurrentes.
Tema 3 Exclusion mutua

16

8.2

Bloque tematico 2: Herramientas para manejar la concurrencia

En la seccion 3.1 se hace una introduccion al problema. En la 3.2 (tipos de sincronizacion y su solucion) se plantea el problema de la exclusion mutua y su division entre
soluciones con espera activa y sin espera activa. Tambien se plantea el problema de la
condicion de sincronizacion. En la seccion 3.3 (soluciones con espera ocupada) excepto
3.3.5 (algoritmo de Eisenberg-McGuire) y 3.3.6 (algoritmo de Lamport) se estudian varios algoritmos, algunos de ellos incorrectos, otros correctos pero con problemas inaceptables y finalmente algunas soluciones aceptables desde el punto de vista teorico basadas
en espera activa. Al terminar de estudiar este tema, los conocimientos mnimos que se
deben haber adquirido son:
Las diferencias principales entre las soluciones con espera activa y sin esperada
activa.
Ser capaz de distinguir una solucion con espera activa correcta al problema de
la exclusion mutua de una incorrecta. Tambien distinguir, entre las correctas, las
aceptables de las inaceptables y poder explicar por que (alternancia, espera infinita,. . . ).
Las soluciones hardware explicadas en el texto base quedan fuera del a mbito de la asignatura. Lo u nico que el estudiante requiere saber es que todas las soluciones software
al problema de la exclusion mutua son de una ineficiencia tal que resulta evidente que
la exclusion mutua debe implementarse a nivel de hardware. La forma concreta de estas soluciones hardware de bajo nivel es irrelevante para nosotros, que nos centraremos
en como aprovechar las posibilidades para la exclusion mutua de las herramientas para
manejar la concurrencia que son el objeto del siguiente bloque tematico.

8.2.

Bloque tematico 2: Herramientas para manejar la concurrencia

En este bloque se discuten diversos conjuntos de herramientas que se han propuesto teoricamente para manejar la concurrencia. Dichas herramientas estan implementadas en proporcion desigual en los lenguajes de programacion. Mientras algunas de ellas, como los semaforos, han sido aceptadas de forma casi universal, otras han retenido su condicion de propuestas
mas teoricas. Es digno de mencion sin embargo, que otras han superado este status en fechas
relativamente recientes, como es el caso de la programacion orientada a sucesos o eventos,
popularizada con el uso de las interfaces graficas de usuario y la programacion orientada a
objetos. El proceso inverso, conjuntos de herramientas diferentes de los clasicos, pero implementados por los lenguajes de uso frecuente, como podra ser el objeto protegido de Ada y las
primitivas wait y notify de Java, tambien son frecuentes. En este bloque tematico se estudia
tambien como superar esta separacion entre propuestas teoricas y lo que de verdad esta disponible a la hora de programar. La PC es un campo que evoluciona rapidamente, por lo que
el estudiante comprobara que es difcil establecer cuales son dichas diferencias. El caso de

17

8.2

Bloque tematico 2: Herramientas para manejar la concurrencia

Java es paradigmatico en este sentido, ya que implementa de forma nativa primitivas de concurrencia no disponibles anteriormente en dicho lenguaje a una velocidad sorprendente, que
convierte en obsoletas algunas de las recomendaciones del texto base.
Todas las herramientas para manejar la concurrencia tienen la misma potencia y expresividad. No hay nada que pueda hacerse con una de ellas que no pueda hacerse con otra. Sin
embargo, los distintos planteamientos pueden producir resultados muy diferentes en cada problema concreto. La eleccion de una de ellas para un problema concreto puede venir forzada por
el planteamiento o por el lenguaje, ser una cuestion de preferencias personales o el resultado
de un compromiso entre elegancia y eficiencia.

8.2.1.

Objetivos

El estudiante debera familiarizarse con estas herramientas y ser consciente de sus diferencias. Las caractersticas de una herramienta concreta, o la simulacion de una de ellas mediante
la otra suelen ser objeto de evaluacion por parte del equipo docente.

Temas

4. SEMAFOROS
Introduccion
Definicion de un semaforo
Inconvenientes de los semaforos
5. REGIONES CRITICAS CONDICIONALES (RCC)
Introduccion
Definicion de RCC
Inconvenientes de las RCC
6. MONITORES
Introduccion
Definicion de monitor
Condicion de sincronizacion
Semantica de la operacion resume
7. BUZONES
18

8.3

Orientaciones especficas de los temas

Introduccion
Identificacion en el proceso de comunicacion
Sincronizacion
Canal de comunicacion y mensajes
Espera selectiva
Funcionamiento de los buzones
REMOTA
8. INVOCACION
Introduccion
Funcionamiento de la invocacion remota
9. EQUIVALENCIA DE HERRAMIENTAS

8.3.

Orientaciones especficas de los temas

Tema 4 Semaforos.
Los semaforos pueden estudiarse en el captulo 4 del texto base, en concreto en las
secciones 4.1 (introduccion), 4.2 (definicion de un semaforo), y 4.6 (inconvenientes del
mecanismo de los semaforos).
Los semaforos son indiscutiblemente la herramienta de PC mas popular y mas extendida.
Todos los sistemas operativos multiprogramados estan programados usando semaforos
como herramienta de sincronizacion entre procesos. Las razones son claras: Se trata de
una herramienta de bajo nivel que se puede implementar de forma casi inmediata por
hardware en cualquier arquitectura que lo admita y ademas permite un grado de control y flexibilidad que no es posible con ninguna otra herramienta de sincronizacion.
Ademas, practicamente todos los lenguajes de programacion con posiblidades de concurrencia los implementan de forma nativa, as que un programa concurrente concebido
con semaforos sera facilmente portable a cualquier lenguaje y cualquier plataforma, al
menos en lo que se refiere a los aspectos concurrentes.
Por otro lado, las desventajas de los semaforos son considerables. Se trata de una herramienta de muy bajo nivel logico. Un programa concurrente con unos pocos semaforos
puede ir desde lo difcil de seguir por parte de un eventual lector a lo directamente incomprensible. Es facil cometer errores y puede resultar complejo encontrarlos. En PC,
el mero hecho de que un programa se ejecute sin problemas durante un buen rato, no es
o bice para que falle al instante siguiente. Los fallos pueden ser de una sutileza desconocida en la programacion secuencial.
Un error frecuente con respecto a los semaforos, es pensar que despues de ejecutar la
sentencia signal sobre un semaforo, un proceso cede la ejecucion a otro. Eso no solo no
19

8.3

Orientaciones especficas de los temas

es as, sino que raras veces ocurre. Basta releer la semantica de la operacion signal para
comprenderlo. Como explicacion adicional de por que no hay motivo para que ocurra
esto, basta pensar en un ordenador con dos procesadores y dos procesos. Si uno de ellos
ejecuta un signal, no hay ninguna razon para que el proceso ceda la CPU al otro proceso,
ya que ambos pueden seguir en ejecucion de forma concurrente.
Es un hecho digno de mencion que las secciones del libro dedicadas a la simulacion
de semaforos mediante las primitivas de Java son tanto obsoletas como posiblemente
incorrectas. Desde hace algunas versiones de Java existe la clase semaphore de forma
nativa. Por otro lado, la simulacion basada en las antiguas primitivas de Java; wait,
notify y notifyall tienen el inconveniente de que al llamar a notify o notifyall, el hilo
que sale del estado bloqueado (del llamado waiting set) se elige de manera aleatoria, lo
cual es contradictorio con la definicion de los semaforos que implica la existencia de
una cola, es decir, que el primero en entrar es el primero en salir. Hay que notar que esta
diferencia de funcionamiento es lo bastante sutil como no afectar de forma perceptible el
comportamiento de los programas, por lo que la simulacion puede usarse en la practica
sin problemas, pese a que ya no hay razon para no usar la implementacion nativa de los
semaforos.
Tema 5 Regiones crticas condicionales
Las regiones crticas condicionales (RCC) se explican en el captulo 5 del texto base,
en particular en las secciones 5.1 (introduccion), 5.2 (definicion de RCC) y 5.5 (inconvenientes del mecanismo de RCC). Las regiones crticas a secas se pueden considerar
como un caso particular de region crtica condicional en la que la condicion siempre es
cierta.
Las regiones crticas condicionales son una herramienta de nivel conceptual superior a
los semaforos. Por algun motivo, es raro que esten implementadas de forma nativa en
lenguajes reales. En cualquier caso, permiten soluciones bastante elegantes para algunos
problemas de PC que resultaran enrevesadas con semaforos. Una diferencia interesante
es el uso de dos colas para bloquear los procesos. Ademas de la cola principal, existe una segunda cola, llamada cola de eventos, que permite que aquellos procesos que
obtuvieron la exclusion mutua y despues la devolvieron por no cumplir la condicion,
tengan preferencia a la hora de reevaluarla ante los procesos que llegan al comienzo de
la region.
Tema 6 Monitores
El temario sobre los monitores se ajusta a lo explicado en el captulo 6 del texto base,
concretamente las secciones 6.1 (introduccion), 6.2 (definicion de monitor), 6.3 (condicion de sincronizacion en monitores), y 6.6 (semantica de la operacion resume).
Los monitores representan el nivel mas elevado en terminos de abstraccion conceptual
en lo que respecta a herramientas de sincronizacion de memoria compartida. Esto los

20

8.3

Orientaciones especficas de los temas

situa en el extremo opuesto a los semaforos, lo que puede observarse en lo complicado que resulta simular un monitor mediante semaforos. Los monitores no han gozado
historicamente de un gran apoyo en terminos de implementacion en lenguajes populares.
El mecanismo de la exclusion mutua es automatico en los procedimientos del monitor,
por lo que el e nfasis se situa logicamente en la sincronizacion. A este respecto, la operacion resume admite cuatro semanticas operacionales distintas. Nosotros adoptaremos
la misma que el texto base, la denominada desbloquear y espera urgente. Con esta
semantica, el proceso que ejecuta una operacion resume sale del monitor y va inmediatamente a una cola llamada cola de cortesa.
Probablemente este comportamiento es que el despista a muchos estudiantes cuando
piensan que un proceso que ejecuta un signal sobre un semaforo tambien se bloquea, lo
que, como ya hemos mencionado, no es cierto. La situacion es completamente diferente.
Aunque tengamos muchos procesadores, la caracterstica principal del monitor es que
solo un proceso puede estar activo dentro de un procedimiento del monitor, de modo
que si se quiere despertar a otro proceso que se quedo bloqueado cuando estaba dentro
del monitor, hay que tomar una decision, pero no pueden estar ejecutandose los dos al
mismo tiempo.
Cuando un proceso ejecuta resume dentro de un monitor pueden pasar dos cosas. La
primera es que no haya ningun proceso bloqueado en la cola de cortesa asociada a
la variable de condicion. En ese caso la sentencia resume no tiene efecto. La otra es
que s haya procesos. Un comentario incorrecto, pero frecuente, es que el proceso que
ejecuta el resume sale del monitor y entra en la cola de cortesa hasta que algun proceso
ejecute resume, momento en el cual el proceso volvera al monitor. La cola de cortesa
es, en efecto, una cola, por lo que si se ejecutan varios resume seguidos, un proceso que
ejecuto resume despues que otros puede tardar bastante en volver a entrar en el monitor;
es decir, no volvera al monitor al primer resume, sino cuando le toque.
La seccion del libro sobre monitores en Java esta totalmente desfasada, ya que desde
hace unas pocas versiones los monitores estan implementados en Java de forma casi
nativa. Una forma sencilla de implementarlos es utilizando las clases Lock y Condition.
Los equivalentes de delay y resume seran los metodos await y signal de Condition.
Un error frecuente con los monitores es usarlos para simular semaforos, definiendo unos
procedimientos exportados wait y signal, para despues utilizar estos wait y signal para
enmarcar una region crtica. Es obvio que resulta mucho mas logico aprovechar el hecho
de que los procedimientos del monitor se ejecutan en exclusion mutua para hacer un
procedimiento que implemente la region crtica. Por otra parte, es un error que demuestra
poca familiaridad con el funcionamiento de los monitores.
Tema 7 Buzones
Los buzones corresponden a los captulos 7 y 8 del texto base. En el captulo 7 se siembran las bases para la comprension de la herramienta buzones, explicando los mecanismos de paso de mensaje. Entran en el temario las secciones 7.1 (introduccion), 7.2
21

8.3

Orientaciones especficas de los temas

(identificacion en el proceso de comunicacion), 7.3 (sincronizacion), 7.4 (canal de comunicacion y mensajes) y 7.6 (espera selectiva). Los buzones propiamente dichos se
explican en el captulo 8, en la seccion 8.1 (introduccion).
En este tema se entra en el campo de las herramientas basadas en paso de mensajes, en
contraposicion a las herramientas basadas en memoria compartida. Las herramientas de
paso de mensajes son las u nicas que se pueden utilizar en arquitecturas distribuidas.
Aunque nada evita en principio utilizar variables compartidas, no es recomendable, ya
que supone una restriccion innecesaria y que priva al programa de la posibilidad de
ejecutarse en sistemas distribuidos. Los buzones en s se suelen declarar en el programa
principal, es decir, estan declarados de forma global, pero no se considera que sean
variables globales, sino mecanismos de comunicacion. Por esa razon, el mero hecho de
usar buzones no significa utilizar memoria compartida.
Conviene recordar que los buzones son herramientas bloqueantes. Si un proceso intenta leer de un buzon vaco, quedara bloqueado hasta que otro proceso escriba en dicho
buzon. Una forma de evitar esta situacion es usar adecuadamente la funcion EMPTY. Si
el buffer es de tamano finito, las operaciones de escritura en el buzon tambien provocan
bloqueo cuando el buffer asociado este lleno. Una excepcion a ambas situaciones es el
uso de la sentencia SELECT.
Otro error comun, quizas influencia de la herramienta canales, es usar un buzon distinto
por cada dos procesos que quieran comunicarse entre ellos. Un mismo buzon puede ser
utilizado por todos los procesos. Un u ltimo error comun es olvidar que la comunicacion
en los buzones puede ser bidireccional. Un proceso puede utilizar un mismo buzon tanto
para leer como para escribir en e l.
Tema 8 Invocacion remota
La herramienta conocida como rendez-vous, cita de Ada o invocacion remota se explica
en el captulo 10 del texto base, en las secciones 10.1 (introduccion) y 10.2 (invocacion
remota).
La invocacion remota es la herramienta de mas alto nivel conceptual de todas las herramientas de sincronizacion basadas en paso de mensajes. Mediante la invocacion remota,
un proceso puede ejecutar un procedimiento de otro proceso que ademas puede (y suele)
estar ejecutandose en otra maquina. La invocacion remota es la herramienta concurrente
mas claramente enfocada al desarrollo de aplicaciones cliente-servidor.
Una diferencia sustancial de la invocacion remota respecto a cualquier otra herramienta
de PC, es que el que uso de invocacion remota suele llevar parejo el uso de procesos adicionales que actuan como servidor o controlador. En particular, la simulacion de otras
herramientas de sincronizacion mediante invocacion remota implica la creacion de nuevos procesos. A este respecto, la simulacion de un semaforo mediante invocacion remota
en la pagina 332 del texto base es bastante clarificadora.

22

8.4

Bloque tematico 3: Problemas de aplicacion

Un error comun es suponer que el empleo de la invocacion remota proporciona de forma

magica exclusion mutua. En primer lugar, es perfectamente posible, y posiblemente
conveniente, utilizar la invocacion remota sin usar memoria compartida. En ese caso la
cuestion ni se plantea. Si se combina memoria compartida e invocacion remota puede
haber problemas, especialmente si tenemos en cuenta que la invocacion remota permite
el paso de parametros en ambas direcciones entre el proceso llamador y el llamado. El
paso de parametros implica copia de los mismos, por lo que si se pasan como parametros
de una invocacion remota variables compartidas, los resultados pueden ser impredecibles.

8.4.

Bloque tematico 3: Problemas de aplicacion

En PC hay dos problemas-tipo cuyo conocimiento es absolutamente imprescindible: Se

trata del problema de los lectores y escritores y del problema de los productores y consumidores. Multitud de los aspectos de colaboracion entre los procesos de un programa concurrente
responden a alguno de estos esquemas, ya sea directamente o mediante variaciones, combinaciones o generalizaciones de los mismos. Solo por este motivo su incorporacion al temario
estara sobradamente justificada, pero ademas, el estudio de su resolucion mediante las diferentes herramientas del segundo bloque tematico supone una excelente manera de comprender
su funcionamiento en la practica.
Por otra parte, es logico suponer que tambien hay problemas que no responden en absoluto
a dichos esquemas algortmicos. El otro problema resuelto en el texto base usando todas las
herramientas de sincronizacion es el problema de la comida de los filosofos. Se trata de un
problema clasico propuesto por Andrew Tanembaum para ilustrar muchos de los problemas
que se producen al intentar solucionar un problema de PC de apariencia inocente, pero que no
tiene una solucion plenamente satisfactoria.

8.4.1.

Objetivos
Reflexionar sobre el uso de cada herramienta y despejar dudas sobre su funcionamiento.
Al completar este bloque tematico, se espera que el estudiante sea capaz de identificar
un problema-tipo si se enfrenta a uno en alguna de las pruebas de la asignatura.

8.5.

Orientaciones sobre los contenidos

Este bloque tematico consta de un u nico tema:

23

9 Actividades

Tema 10 Problemas de aplicacion

Los problemas de aplicacion pueden estudiarse en las siguientes secciones del texto
base: 4.3 (resolucion de problemas usando semaforos), 5.3 (resolucion de problemas
usando RCC), 6.4 (resolucion de problemas usando monitores), la 8.2 (resolucion de
problemas empleando paso de mensajes asncrono) y 10.3 (resolucion de problemas
mediante invocacion remota en PASCAL-FC).
En ocasiones es necesario que varios procesos puedan leer un recurso al mismo tiempo.
Si el recurso no tiene siempre el mismo valor, cosa que tendra poco sentido, tambien
habra procesos que intenten modificarlo. La primera restriccion descarta el acceso en
exclusion mutua al recurso. La segunda descarta el acceder al recurso compartido sin
ningun tipo de sincronizacion. El esquema algortmico de los lectores y escritores es un
ingenioso mecanismo que permite satisfacer ambas restricciones al mismo tiempo. El
texto base trata la cuestion desde un punto de vista bastante teorico. Como la division en
captulos se realiza en funcion de las diferentes herramientas, los problemas resueltos y
propuestos al final de cada captulo suelen restringirse a proponer problemas de ndole
general de cada herramienta concreta. En el curso virtual puede encontrarse una cierta
cantidad de examenes resueltos que enfocan los problemas-tipo.
En la implementacion de lectores y escritores con preferencia para la escritura resuelto
mediante semaforos, en la pagina 101 del texto base, hay una errata: Donde pone ne :=
ne -1;, debera poner escribiendo := false.
El problema-tipo de los productores y consumidores suele provocar menos problemas de
comprension que el de los lectores y escritores, por lo que se recomienda al estudiante
que intensifique su estudio de este segundo.
El problema de la cena de los filosofos no es un problema-tipo, sino mas bien el tipo
de problema que no se ajusta a ningun tipo, por lo que identificar cualquier problema
(excepto el de los filosofos y sus variaciones, claro esta) como un caso del problema-tipo
de los filosofos es un hecho bizarro que se recomienda evitar.

9.

Actividades

En el texto base y la bibliografa complementaria pueden encontrarse numerosos ejercicios

propuestos y resueltos. Del mismo modo, en el curso virtual pueden encontrarse practicas y
examenes de otros anos, algunos de ellos resueltos.

24