Universidad Nacional de Educacion a Distancia

Guıa Didactica

Programacion Concurrente(Ingenierıa Tecnica Informatica de Sistemas)

Equipo docente:

David Fernandez Amoros

.

c©2008 David Fernandez Amoros. Todos los derechos reservados.

2

INDICE

Indice

1. Informacion general 5

1.1. Presentacion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5

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

2. Presentacion de los contenidos 7

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

3. Requisitos previos 8

4. Materiales 9

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 especıficas de los temas . . . . . . . . . . . . . . . . . . . . . . 15

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

8.2.1. Objetivos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18

8.3. Orientaciones especıficas de los temas . . . . . . . . . . . . . . . . . . . . . . . . . . 19

3

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

4

1 Informacion general

1. Informacion general

1.1. Presentacion

Esta guıa pretende orientar al alumno en la planificacion y el estudio de la asignatura.Se recomienda leer la guıa en su totalidad al principio del cuatrimestre para tener una visionde conjunto de la dinamica del curso. Esta informacion se complementa con el enunciadode la practica obligatoria, las preguntas frecuentes y los problemas de examen disponiblesen el curso virtual, de forma que el estudiante pueda planificar desde el principio el estudioy realizacion de la practica para aprovechar el tiempo al maximo y no perder los plazos deentrega.

1.2. Introduccion a la asignatura

El ambito de conocimiento de esta asignatura es el de la programacion en computacionparalela o distribuida. La programacion concurrente (en adelante PC) anade una capa suple-mentaria de complejidad respecto de la secuencial, por cuanto que es una extension de esta, enel sentido de que un programa concurrente esta compuesto por varios programas secuencialesque 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 ne-cesidad de arbitrar mecanismos adecuados para permitir el acceso, ya sea para leer, ya sea paramodificar el recurso compartido, de manera que se garantice que la informacion que proporcio-na en cualquier momento sea coherente. Esta necesidad de coherencia, unida a la articulacionde 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 herra-mientas propuestas historicamente para manejar la ejecucion simultanea de programas juntocon esquemas algorıtmicos desarrollados para el tratamiento de situaciones comunes en PC.Las tecnicas aprendidas se pondran en aplicacion en un trabajo practico de caracter obligatorioen el que se desarrollara un programa concurrente que sirva de modelo a una situacion descritaen el enunciado del mismo.

Los contenidos de esta asignatura se encuentran incluidos en otros planes de estudio dentrolas asignaturas de sistemas operativos o de sistemas en tiempo real, si bien comunmente en di-chas materias la problematica especıfica de la PC no se encuentra desarrollada, ni en extensionni 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 opta-tiva de tercer curso de la titulacion de Ingenierıa Tecnica en Informatica de Sistemas, si bienesta disponible como asignatura de libre configuracion y de libre eleccion dentro de la Escuela

5

1.2 Introduccion a la asignatura

Superior de Ingenierıa Informatica de la UNED. Se imparte durante el primer cuatrimestre deltercer curso.

La evaluacion de la asignatura incluye un trabajo obligatorio de ındole practica por impe-rativo del reglamento del departamento LSI. En la practica obligatoria de la asignatura y enel examen solo se exigira la codificacion de los programas en pseudocodigo, sin embargo, serecomienda encarecidamente que el programa de la practica y los ejercicios se codifiquen yprueben con un lenguaje de programacion concreto. En la bibliografıa de la asignatura se hacehincapie principalmente en los lenguajes PASCAL-FC, Java y en menor medida Ada, aunqueel lenguaje elegido no es importante siempre que se utilicen las herramientas de sincronizacionpertenecientes al temario, aunque sea de forma simulada. Cada uno de ellos tiene sus ventajase inconvenientes:

PASCAL-FC es el decano de los lenguajes de programacion concurrente, no tanto porsu antiguedad sino por el hecho de no haber sido actualizado desde hace decadas. Conimplementaciones para DOS, Windows y Linux, sus ventajas son la simplicidad dellenguaje, que tiene las mınimas caracterısticas de programacion, y la variedad de he-rramientas de concurrencia que soporta. Existen editores especıficos para Windows eincluso un plugin para el entorno de programacion multiplataforma ECLIPSE. Entre lasdesventajas, se podrıa mencionar que tiene un cuarto de siglo con todo lo que ello con-lleva, restricciones absurdas hoy en dıa respecto al numero maximo de procesos y demonitores, falta de tipos de datos basicos como serıan las cadenas de caracteres (soloexiste el tipo caracter) y hasta maximo numero de instrucciones ejecutadas. Un pro-grama que ejecute 200000 instrucciones es abortado y automaticamente sospechoso delivelock. Tampoco hay manera de definir una funcion dentro de un monitor, aunque teori-camente es posible. Estas limitaciones pueden ser severas incluso a la hora de realizar lapractica de la asignatura.

Java es un lenguaje de proposito general, multiplataforma y constantemente moderni-zado. Existen editores y documentacion de todo tipo. Si bien las limitaciones de susimplementaciones en diversas plataformas y el hecho de ser muy a menudo interpretadopueden afectar negativamente sus posibilidades reales, sus limitaciones estan a anos luzde las de PASCAL-FC. Aunque sus primitivas de sincronizacion inicialmente no tenıannada que ver con las estudiadas en la asignatura, hoy en dıa la situacion ha mejoradoconsiderablemente. El punto mas debil de Java para esta asignatura es que requiere elaprendizaje de un lenguaje complejo, mientras que PASCAL-FC es casi inmediato.

Ada es un lenguaje de proposito general, multiplataforma. Se considera un lenguaje es-pecializado. 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. Susprimitivas de concurrencia apenas coinciden con las del temario de la asignatura, exceptoen 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 posibilidadesde uso fuera del departamento de defensa de los Estados Unidos de America, donde fuedesarrollado originalmente.

La PC se ha restringido tradicionalmente a unas areas de aplicacion muy concretas, perode una importancia incuestionable:

Sistemas empotrados: Sistemas sencillos, habitualmente sin sistema operativo, en unhardware especıfico, en los que unos programas que se ejecutan concurrentemente leenunos sensores y toman decisiones como activar o desactivar otros componentes electroni-cos. Un ejemplo sencillo serıa un termostato.

Sistemas operativos: En un sistema operativo multiprogramado lo normal es que hayavarios procesos ejecutandose en paralelo (ya se trate de paralelismo real o simulado). Esnecesario sincronizar dichos procesos para que los programas del sistema y los de losusuarios puedan compartir los recursos de la maquina. Un caso particular pero especial-mente relevante serıa el de los sistemas operativos distribuidos.

Sistemas de Gestion de Bases de Datos: Los SS.GG.BB.DD tienen entre sus objetivosde diseno el proporcionar un acceso eficiente a los datos manteniendo la consistenciade los mismos. Para permitir el acceso simultaneo de varios programas y mantener almismo tiempo la consistencia de los datos entre las transacciones, se aplican tecnicas dePC.

Computacion en malla: Se utilizan muchos ordenadores, conectados en red, para realizarun 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 coordinadamenteindicios de vida extraterrestre.

Pese a sus comienzos especializados, en la informatica de consumo se ha popularizado enlos ultimos tiempos el uso de sistemas multiprocesador. En estas CPU’s con dos, tres o cuatronucleos, las ventajas de la PC son incluso mas claras que en un entorno monoprocesador, loque hace previsible un aumento de la demanda de profesionales con conocimientos solidos eneste campo.

2. Presentacion de los contenidos

Tras presentar algunos conceptos fundamentales de la PC, el foco se desplaza al uso detecnicas 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 ambito de la memoria compartida: semafo-ros, regiones crıticas, regiones crıticas condicionales y monitores. En los temas siguientes seintroducen los conceptos asociados al paso de mensajes y algunas de las herramientas corres-pondientes, en concreto buzones e invocacion remota. En todos los temas referentes a herra-mientas concretas se estudian soluciones a los dos problemas-tipo de la PC, que pueden versecomo esquemas algorıtmicos: El problema de los lectores y escritores y el problema de losproductores y consumidores. Otro aspecto transversal es el de la equivalencia de las distintasherramientas; el comportamiento de cualquier herramienta puede simularse mediante otra, apesar de lo cual todas ellas poseen caracterısticas distintivas que hacen que unas sean masapropiadas que otras frente a un problema concreto.

2.1. Objetivos generales

Presentar los problemas derivados de la ejecucion simultanea de tareas

Introducir esquemas algorıtmicos generales aplicables a numerosos problemas

Adiestrar al estudiante en el empleo de diversas herramientas de sincronizacion de pro-cesos

Desarrollar la capacidad de analisis y diseno de soluciones a un problema de simulacionmediante el uso de tecnicas aprendidas en la asignatura

3. Requisitos previos

En un modelo de capas o niveles de abstraccion, la PC se encontrarıa en un nivel superioral de la programacion convencional. Dado que es el sistema el que proporciona la concurren-cia, lo que corresponde al programador es administrar dicha concurrencia, de forma que lasdiferentes partes de un programa concurrente calculen juntas un resultado al tiempo que semantiene la consistencia de los datos. Las tecnicas de programacion secuencial se dan por su-puestas. Sin embargo, dicho esto hay que matizar que el enfasis de la materia se centra en losmecanismos de sincronizacion de procesos, por lo que no se presta demasiada atencion a losaspectos formales y metodologicos de la programacion. Por tal motivo, los unicos requisitosprevios serıan un conocimiento solido de los contenidos correspondientes a la asignatura Pro-gramacion I, de primer curso. Serıa util, aunque no imprescindible, que el alumno tuviera unacierta 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 ultimo, el con-tenido de la asignatura se relaciona con el de Sistemas Operativos I, de segundo curso, por loque respecta a la relacion de los estados de un programa concurrente en relacion con el sistemaoperativo, 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 enella se dedica un tema de estudio a la PC. Evidentemente, el enfoque de aquella resulta masligero, por lo que su estudio podrıa proporcionar una introduccion a los temas desarrolladosen esta asignatura.

Dejando de lado algunas cuestiones de estilo de programacion, los problemas habitualesde la asignatura no suelen estar relacionados con un aprendizaje deficiente de asignaturas an-teriores, por lo que no se considera necesario reforzar capacidades anteriores. Se recomiendaque 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 compilaciony 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 nu-merosos ejemplos de aplicacion y ejercicios resueltos. Tambien se proponen problemas porresolver, de modo que resulta un texto adecuado para el aprendizaje a distancia. Es cierto queen algunas de sus consideraciones practicas, como la implementacion en Java de algunas delas tecnicas, ya esta obsoleto debido al rapido avance de la tecnica, pero afortunadamente, lapresentacion de los conceptos y tecnicas es completamente actual.

El alumno encontrara en el curso virtual materiales adicionales para el seguimiento de laasignatura. Entre ellos, enunciados de examenes anteriores, examenes resueltos, demostracio-nes de simulaciones realizadas aplicando las tecnicas objeto de estudio, ası como compiladoresy documentacion sobre lenguajes de programacion con posibilidades de concurrencia. Comoresultado de un seguimiento de las dificultades de los alumnos en relacion con la asignatura, seha realizado un lista de preguntas frecuentes para optimizar el proceso de aprendizaje y evitarla sobrecarga del equipo docente, que redunda en unos tiempos de respuesta mas largos a lasdudas del alumnado. Una parte del mismo material se ha incluido en el DVD de la Escuela Su-perior de Ingenierıa Informatica, para aquellos alumnos a los que les resulte mas convenienteeste medio.

La bibliografıa complementaria consta de las siguientes obras:

Programacion concurrente. 2a edicion corregida, Perez Martınez, J. E., Madrid, Edito-rial Rueda, 1990.

9

5 Orientaciones generales para el estudio

Durante algunos anos, esta obra fue el texto base de la asignatura. Esta obra peca quizasde 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, labibliografıa basica menciona rapidamente aspectos vitales, como pueden ser la necesi-dad absoluta de la exclusion mutua en los accesos no compatibles, o las causas de losinterbloqueos y las polıticas para evitarlo, pero no los subraya. Este libro profundizateoricamente y ejemplifica los conceptos. El analisis de los puntos fuertes y debiles decada una estas obras en relacion con la otra permite obtener una vision de conjunto dela disciplina mucho mas completa, y altamente recomendable, que la proporcionada porcada una de ellas individualmente.

Principles of Concurrent and Distributed Programming. 2o Edicion, Ben-Ari, M., Addison-Wesley, 2006

Mordechai Ben-Ari es una de las figuras de referencia de la PC actual. Este matematicoisraelı, premiado por sus contribuciones a la ensenanza de la informatica ha sido unactivo colaborador en el desarrollo del lenguaje Ada. Una prueba de lo influyente deesta obra, desde la primera edicion en 1990, la da la mera comparacion de su ındice conel 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 exper-tos en el campo de la computacion distribuida. Las caracterısticas concurrentes formanparte de los principios de diseno de Ada, hecho este que lo diferencia de la mayorıa delos lenguajes de programacion con posibilidades de concurrencia, en las que estas nosuponen mas que un anadido a posteriori.

5. Orientaciones generales para el estudio

Una primera lectura rapida del libro puede proporcionar una adecuada vision de conjuntode los problemas que se van a tratar. En esta primera lectura se pueden ignorar los apartadosrelativos a la puesta en practica de la teorıa en los diversos lenguajes considerados (PASCAL-FC, Java y Ada). La primera unidad didactica se corresponde con parte de los tres primeroscapıtulos del texto base, que pueden considerarse como una introduccion extendida a los con-ceptos fundamentales de la PC. La informacion relevante de estos capıtulos puede ser extraıdaen 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 estanentremezcladas en el texto. Esta parte del libro puede estudiarse siguiendo el esquema dedistribucion 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 soluciona los problemas-tipo utilizando dicha herramienta. Este enfoque ofrece la ventaja de que elestudiante se familiariza rapidamente con los problemas que se resuelven y pronto solo leresulta novedosa la solucion que emplea la herramienta especıfica considerada.

Estas dos unidades didacticas se merecen una segunda lectura mas interpretativa. En primerlugar, para ser capaz de programar correctamente una solucion a un problema concreto, esnecesario dominar los detalles de cada herramienta. Cada herramienta consta de una sintaxis,semantica y conjunto de estados especıfico para los procesos (con sus diversos circuitos decolas de espera asociadas) que deben conocerse y manejarse con soltura. Un ejercicio muyutil para aclarar dudas y retener conceptos es implementar las primitivas de una herramientautilizando otra. Este ejercicio tiene ademas la ventaja de que a menudo un lenguaje de PC nosoporta de forma nativa mas que unas pocas herramientas de sincronizacion, de forma que siqueremos usar otras deberemos primero simularlas mediante esas herramientas nativas. Otroaspecto sobre el que conviene reflexionar a medida que se estudia el texto base, es el compararunas herramientas de sincronizacion con otras. No hay herramientas mejores que otras, puestoque a nivel teorico todas son equivalentes, pero sı se pueden clasificar segun sean de alto obajo nivel, sirvan para cualquier arquitectura, caso de las de paso de mensajes, o solo seanaptas para entornos de memoria compartida, etc. . . En una situacion concreta, es muy posibleque haya unas herramientas mas adecuadas que otras, por ello hay que intentar ser conscientede las diferencias entre ellas.

En cualquier caso, tras esa primera lectura es cuando se puede comenzar a trabajar lapractica obligatoria de la asignatura, aunque este trabajo se limite a poco mas que el analisisdel 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 programarsin leerse el libro apenas, o sin haberlo leıdo en absoluto. Habida cuenta de la abundancia dematerial sobre programacion disponible en la Red, esta posibilidad supone una tentacion, sinembargo dicho enfoque suele dejar unas lagunas que terminan suponiendo un grave lastre, quees detectado por el equipo docente mas tarde de lo que serıa deseable (tıpicamente despues dela primera entrega de la practica, lo que lleva a hacer una segunda entrega no deseada previa-mente 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, sepuede analizar el enunciado de la practica y tomar una decision sobre la herramienta que seva a utilizar en la practica obligatoria. Resulta vital analizar si el problema de la practica sepuede asimilar de alguna manera a algun problema-tipo. Como solo hay dos problemas-tipo,la comprobacion no deberıa ser difıcil. A continuacion, se puede estudiar detenidamente di-cha herramienta, de modo que el trabajo sobre la practica pueda ser llevado paralelamente alestudio del resto del temario.

11

6 Distribucion del tiempo de estudio

Unidad Temario Horas de estudioDidactica Teorıa Practica

Tema 1. Introduccion 2I Tema 2. Procesos vs. hilos 1

Tema 3. Exclusion mutua 2Tema 4. Semaforos 3Tema 5. Regiones Crıticas Condicionales 2

II Tema 6. Monitores 3 20Tema 7. Buzones 3Tema 8. Invocacion Remota 3Tema 9. Equivalencia de Herramientas 3

III 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 teorıay dos de practica. Un credito equivale a diez horas de estudio, lo que resulta en cincuentahoras de estudio. En la figura 6 se puede ver la temporizacion propuesta. Se propone un plande trabajo de unas dos horas y media de estudio teorico por semana. A partir de la tercerasemana, el estudio teorico se combina con la realizacion de la practica a razon de unas doshoras por semana.

7. Evaluacion

7.1. Pruebas de evaluacion

La calificacion de la asignatura tendra en cuenta la calificacion de la practica obligatoriade la asignatura y la calificacion de la prueba presencial. Para aprobar la asignatura, tanto lapractica como la prueba presencial deben estar aprobadas. La nota de la practica en una convo-catoria 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, aun-que en algunos casos excepcionales puede aumentar o disminuir ligeramente la calificaciontotal. En el SIRA solo quedara reflejada la calificacion global, aunque en el curso virtual apa-recera detallada la calificacion de la practica. No hay pruebas de evaluacion a distancia. Lapractica 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 convo-catoria, por lo que si las nota de la practica esta disponible antes de los examenes y no ha sidosuperada, 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 lapractica. El programa del examen requiere la puesta en practica de los conocimientos adquiri-dos durante el estudio de la asignatura, pero habitualmente no suele consistir en una aplicacioninmediata de un concepto teorico o problema-tipo. Es frecuente que se mezclen los problemas-tipo de alguna forma, e incluso que sea necesario generalizar y combinar los problemas-tipode forma no trivial y con cierto grado de creatividad. Tambien ocurre con frecuencia que elprograma del examen no responda claramente a un esquema algorıtmico. En funcion de lacomplejidad del mismo, puede haber tambien cuestiones teorico-practicas. Los criterios deevaluacion 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 laprogramacion secuencial. Se motiva la necesidad y conveniencia de la PC, y se realizan algunasconsideraciones sencillas sobre su implementacion a bajo nivel. Tambien se introducen losconceptos de proceso e hilo, lo que permite profundizar en la problematica de la PC en generaly 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 diferenciasesenciales entre la PC y la secuencial, ası como ser consciente de las diferentes arquitecturasfısicas de los sistemas en los que puede emplearse la PC. Una de estas caracterısticas anadidases el concepto de estado del de un proceso. En programacion clasica los estados de un pro-grama son limitados; el sistema operativo carga y lanza el programa, que se ejecuta hasta sufinalizacion. En PC cada proceso o hilo es un correlato del programa secuencial, pero puedeencontrarse en un conjunto de estados mayor. Estos estados adicionales se derivan del hechode que los procesos tienen que sincronizarse entre ellos, lo que a menudo significa que algunosde ellos deben esperar a que otros hayan realizado parte de su tarea. El otro gran problema dela PC es el de la exclusion mutua. Dos procesos no deben acceder concurrente a un mismorecurso (como una variable compartida o un periferico) de forma no compatible. Una vez queun programa concurrente se sincroniza en sus diversas partes correctamente y preserva la ex-clusion mutua a los recursos no compartibles, se puede considerar correcto. Sin embargo, hayotros problemas graves que pueden hacer poco aceptable un programa concurrente correcto.Algunos de estos problemas son la inanicion, el establecimiento de turnos, la baja concurren-cia, la espera activa y el interbloqueo. El interbloqueo se trata extensamente en el libro dePerez Garcıa, donde se discuten tecnicas diferenciadas para detectarlo, evitarlo y prevenirlo.

El estudiante debera ser capaz de identificar estas situaciones para poder evitarlas emplean-do 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

Caracterısticas 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 especıficas de los temas

Tema 1 IntroduccionLa introduccion a la Programacion Concurrente, como toda la asignatura, puede estu-diarse por el libro de Palma et al., en adelante texto base. La secciones que proporcionanuna introduccion a los conceptos fundamentales de la PC, son la 1.1 (introduccion) juntocon la 1.2 (concepto de PC), 1.3 (beneficios de la PC), 1.4 (concurrencia e arquitecturashardware), 1.5 (especificacion de ejecucion concurrente), 1.6 (caracterısticas de los sis-temas concurrentes), 1.7 (problemas inherentes a la PC) y 1.8 (correccion de programasconcurrentes).

El estudio de este tema debe proporcionar al estudiante una vision de conjunto de la pro-blematica de la PC y de algunas caracterısticas diferenciales respecto a la programacionsecuencial. En particular, las diferentes arquitecturas hardware posibles, el concepto detraza de ejecucion y el indeterminismo tienen una influencia determinante en PC. Junto alos 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 nodebe hacer ninguna suposicion sobre la arquitectura del sistema en el que se ejecuta. Unprograma concurrente se puede ejecutar en un entorno monoprocesador multiprograma-do, en el cual no se produce concurrencia real sino que se simula. Sin embargo, tambienes frecuente (quiza lo mas frecuente en nuestros dıas) que la maquina cuente con variosprocesadores, de manera que, de hecho, haya varios procesos ejecutandose en el mismomomento.

El programador, en principio, solo deberıa preocuparse de saber si la arquitectura admitememoria compartida o, por el contrario, se trata de un sistema distribuido. En el primercaso, todas las primitivas de sincronizacion pueden ser consideradas, en el segundo, sololas 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 ejecutarde forma concurrente y lo que no, aunque como resumen, se puede decir que cualquiernumero de procesos puede leer de un determinado recurso de forma concurrente. Sinembargo, el que haya un proceso escribiendo en el recurso lo hace incompatible tantocon otros procesos escritores como con procesos lectores.

Esta cuestion esta estrechamente relacionada con la del indeterminismo. Si bien el in-determinismo en programacion no es negativo per se (imaginemos, por ejemplo, ungenerador de numeros pseudoaleatorios) un programa concurrente querra en la mayorıade los casos mantener cierta coherencia en los datos. En el ejemplo de la subseccion1.6.2, vemos como un acceso no controlado a una variable hace que el valor de la mismasea impredecible. Pensemos ahora en un programa que controle el funcionamiento deuna red de cajeros automaticos. Podemos querer cierta concurrencia, pero seguramenteno queremos que se cree ni se destruya dinero en el proceso. La forma correcta de en-focar el problema tiene que garantizar el acceso en exclusion mutua a las cuentas en losaccesos incompatibles con las condiciones de Bernstein.

Esta cuestion es lo suficiente importante como para repetirla una vez mas: Una variablecompartida debe ser accedida siempre en exclusion mutua, salvo en los casos en los quese asegure que no hay ningun otro proceso intentando modificar dicha variable al mismotiempo. En la practica, esto significa que las variables compartidas deben accedidas (yasea para leer o para modificar sus valores) en exclusion mutua, salvo que se desarrolleun esquema de lectores y escritores, objeto de estudio del tercer bloque tematico.

Tema 2 Procesos vs. hilosEn el segundo capıtulo del libro de Palma et al. se profundiza en las diferencias entreprocesos e hilos en las secciones 2.1 (procesos) y 2.3 (hilos) Los conceptos mas impor-tantes 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 sincro-nizacion.

Excepcion hecha de las dos secciones mencionadas, el resto de este capıtulo del libro noesta muy relacionado con el contenido de la asignatura. Contiene multitud de detallestecnicos que son a la vez demasiado avanzados y relativamente irrelevantes a la hora decomprender conceptualmente la asignatura. En algun caso la informacion allı expuestapuede servir para el estudiante a la hora de codificar y ejecutar sus programas concu-rrentes.

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 sincroni-zacion y su solucion) se plantea el problema de la exclusion mutua y su division entresoluciones con espera activa y sin espera activa. Tambien se plantea el problema de lacondicion de sincronizacion. En la seccion 3.3 (soluciones con espera ocupada) excepto3.3.5 (algoritmo de Eisenberg-McGuire) y 3.3.6 (algoritmo de Lamport) se estudian va-rios algoritmos, algunos de ellos incorrectos, otros correctos pero con problemas inacep-tables y finalmente algunas soluciones aceptables desde el punto de vista teorico basadasen espera activa. Al terminar de estudiar este tema, los conocimientos mınimos que sedeben haber adquirido son:

• Las diferencias principales entre las soluciones con espera activa y sin esperadaactiva.

• Ser capaz de distinguir una solucion con espera activa correcta al problema dela exclusion mutua de una incorrecta. Tambien distinguir, entre las correctas, lasaceptables de las inaceptables y poder explicar por que (alternancia, espera infini-ta,. . . ).

Las soluciones hardware explicadas en el texto base quedan fuera del ambito de la asig-natura. Lo unico que el estudiante requiere saber es que todas las soluciones softwareal problema de la exclusion mutua son de una ineficiencia tal que resulta evidente quela exclusion mutua debe implementarse a nivel de hardware. La forma concreta de es-tas soluciones hardware de bajo nivel es irrelevante para nosotros, que nos centraremosen como aprovechar las posibilidades para la exclusion mutua de las herramientas paramanejar 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 teori-camente para manejar la concurrencia. Dichas herramientas estan implementadas en propor-cion desigual en los lenguajes de programacion. Mientras algunas de ellas, como los semafo-ros, han sido aceptadas de forma casi universal, otras han retenido su condicion de propuestasmas teoricas. Es digno de mencion sin embargo, que otras han superado este status en fechasrelativamente 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 aobjetos. El proceso inverso, conjuntos de herramientas diferentes de los clasicos, pero imple-mentados por los lenguajes de uso frecuente, como podrıa ser el objeto protegido de Ada y lasprimitivas wait y notify de Java, tambien son frecuentes. En este bloque tematico se estudiatambien como superar esta separacion entre propuestas teoricas y lo que de verdad esta dis-ponible a la hora de programar. La PC es un campo que evoluciona rapidamente, por lo queel estudiante comprobara que es difıcil 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 con-currencia no disponibles anteriormente en dicho lenguaje a una velocidad sorprendente, queconvierte en obsoletas algunas de las recomendaciones del texto base.

Todas las herramientas para manejar la concurrencia tienen la misma potencia y expresi-vidad. No hay nada que pueda hacerse con una de ellas que no pueda hacerse con otra. Sinembargo, los distintos planteamientos pueden producir resultados muy diferentes en cada pro-blema concreto. La eleccion de una de ellas para un problema concreto puede venir forzada porel planteamiento o por el lenguaje, ser una cuestion de preferencias personales o el resultadode un compromiso entre elegancia y eficiencia.

8.2.1. Objetivos

El estudiante debera familiarizarse con estas herramientas y ser consciente de sus diferen-cias. Las caracterısticas de una herramienta concreta, o la simulacion de una de ellas mediantela 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 especıficas de los temas

Introduccion

Identificacion en el proceso de comunicacion

Sincronizacion

Canal de comunicacion y mensajes

Espera selectiva

Funcionamiento de los buzones

8. INVOCACION REMOTA

Introduccion

Funcionamiento de la invocacion remota

9. EQUIVALENCIA DE HERRAMIENTAS

8.3. Orientaciones especıficas de los temas

Tema 4 Semaforos.

Los semaforos pueden estudiarse en el capıtulo 4 del texto base, en concreto en lassecciones 4.1 (introduccion), 4.2 (definicion de un semaforo), y 4.6 (inconvenientes delmecanismo de los semaforos).

Los semaforos son indiscutiblemente la herramienta de PC mas popular y mas extendida.Todos los sistemas operativos multiprogramados estan programados usando semaforoscomo herramienta de sincronizacion entre procesos. Las razones son claras: Se trata deuna herramienta de bajo nivel que se puede implementar de forma casi inmediata porhardware en cualquier arquitectura que lo admita y ademas permite un grado de con-trol y flexibilidad que no es posible con ninguna otra herramienta de sincronizacion.Ademas, practicamente todos los lenguajes de programacion con posiblidades de con-currencia los implementan de forma nativa, ası que un programa concurrente concebidocon semaforos sera facilmente portable a cualquier lenguaje y cualquier plataforma, almenos en lo que se refiere a los aspectos concurrentes.

Por otro lado, las desventajas de los semaforos son considerables. Se trata de una herra-mienta de muy bajo nivel logico. Un programa concurrente con unos pocos semaforospuede ir desde lo difıcil de seguir por parte de un eventual lector a lo directamente in-comprensible. 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 esobice para que falle al instante siguiente. Los fallos pueden ser de una sutileza descono-cida en la programacion secuencial.

Un error frecuente con respecto a los semaforos, es pensar que despues de ejecutar lasentencia signal sobre un semaforo, un proceso cede la ejecucion a otro. Eso no solo no

19

8.3 Orientaciones especıficas de los temas

es ası, sino que raras veces ocurre. Basta releer la semantica de la operacion signal paracomprenderlo. Como explicacion adicional de por que no hay motivo para que ocurraesto, basta pensar en un ordenador con dos procesadores y dos procesos. Si uno de ellosejecuta 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 simulacionde semaforos mediante las primitivas de Java son tanto obsoletas como posiblementeincorrectas. Desde hace algunas versiones de Java existe la clase semaphore de formanativa. 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 hiloque sale del estado bloqueado (del llamado waiting set) se elige de manera aleatoria, locual es contradictorio con la definicion de los semaforos que implica la existencia deuna cola, es decir, que el primero en entrar es el primero en salir. Hay que notar que estadiferencia de funcionamiento es lo bastante sutil como no afectar de forma perceptible elcomportamiento de los programas, por lo que la simulacion puede usarse en la practicasin problemas, pese a que ya no hay razon para no usar la implementacion nativa de lossemaforos.

Tema 5 Regiones crıticas condicionalesLas regiones crıticas condicionales (RCC) se explican en el capıtulo 5 del texto base,en particular en las secciones 5.1 (introduccion), 5.2 (definicion de RCC) y 5.5 (incon-venientes del mecanismo de RCC). Las regiones crıticas a secas se pueden considerarcomo un caso particular de region crıtica condicional en la que la condicion siempre escierta.

Las regiones crıticas condicionales son una herramienta de nivel conceptual superior alos semaforos. Por algun motivo, es raro que esten implementadas de forma nativa enlenguajes reales. En cualquier caso, permiten soluciones bastante elegantes para algunosproblemas de PC que resultarıan enrevesadas con semaforos. Una diferencia interesantees el uso de dos colas para bloquear los procesos. Ademas de la cola principal, exis-te una segunda cola, llamada cola de eventos, que permite que aquellos procesos queobtuvieron 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 dela region.

Tema 6 MonitoresEl temario sobre los monitores se ajusta a lo explicado en el capıtulo 6 del texto base,concretamente las secciones 6.1 (introduccion), 6.2 (definicion de monitor), 6.3 (condi-cion de sincronizacion en monitores), y 6.6 (semantica de la operacion resume).

Los monitores representan el nivel mas elevado en terminos de abstraccion conceptualen lo que respecta a herramientas de sincronizacion de memoria compartida. Esto los

20

8.3 Orientaciones especıficas de los temas

situa en el extremo opuesto a los semaforos, lo que puede observarse en lo complica-do que resulta simular un monitor mediante semaforos. Los monitores no han gozadohistoricamente 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 enfasis se situa logicamente en la sincronizacion. A este respecto, la ope-racion resume admite cuatro semanticas operacionales distintas. Nosotros adoptaremosla misma que el texto base, la denominada ”desbloquear y espera urgente”. Con estasemantica, el proceso que ejecuta una operacion resume sale del monitor y va inmedia-tamente a una cola llamada cola de cortesıa.

Probablemente este comportamiento es que el despista a muchos estudiantes cuandopiensan que un proceso que ejecuta un signal sobre un semaforo tambien se bloquea, loque, como ya hemos mencionado, no es cierto. La situacion es completamente diferente.Aunque tengamos muchos procesadores, la caracterıstica principal del monitor es quesolo un proceso puede estar activo dentro de un procedimiento del monitor, de modoque si se quiere despertar a otro proceso que se quedo bloqueado cuando estaba dentrodel monitor, hay que tomar una decision, pero no pueden estar ejecutandose los dos almismo tiempo.

Cuando un proceso ejecuta resume dentro de un monitor pueden pasar dos cosas. Laprimera es que no haya ningun proceso bloqueado en la cola de cortesıa asociada ala variable de condicion. En ese caso la sentencia resume no tiene efecto. La otra esque sı haya procesos. Un comentario incorrecto, pero frecuente, es que el proceso queejecuta el resume sale del monitor y entra en la cola de cortesıa hasta que algun procesoejecute resume, momento en el cual el proceso volvera al monitor. La cola de cortesıaes, en efecto, una cola, por lo que si se ejecutan varios resume seguidos, un proceso queejecuto 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 desdehace unas pocas versiones los monitores estan implementados en Java de forma casinativa. Una forma sencilla de implementarlos es utilizando las clases Lock y Condition.Los equivalentes de delay y resume serıan los metodos await y signal de Condition.

Un error frecuente con los monitores es usarlos para simular semaforos, definiendo unosprocedimientos exportados wait y signal, para despues utilizar estos wait y signal paraenmarcar una region crıtica. Es obvio que resulta mucho mas logico aprovechar el hechode que los procedimientos del monitor se ejecutan en exclusion mutua para hacer unprocedimiento que implemente la region crıtica. Por otra parte, es un error que demuestrapoca familiaridad con el funcionamiento de los monitores.

Tema 7 BuzonesLos buzones corresponden a los capıtulos 7 y 8 del texto base. En el capıtulo 7 se siem-bran las bases para la comprension de la herramienta buzones, explicando los meca-nismos de paso de mensaje. Entran en el temario las secciones 7.1 (introduccion), 7.2

21

8.3 Orientaciones especıficas de los temas

(identificacion en el proceso de comunicacion), 7.3 (sincronizacion), 7.4 (canal de co-municacion y mensajes) y 7.6 (espera selectiva). Los buzones propiamente dichos seexplican en el capıtulo 8, en la seccion 8.1 (introduccion).

En este tema se entra en el campo de las herramientas basadas en paso de mensajes, encontraposicion a las herramientas basadas en memoria compartida. Las herramientas depaso de mensajes son las unicas que se pueden utilizar en arquitecturas distribuidas.

Aunque nada evita en principio utilizar variables compartidas, no es recomendable, yaque supone una restriccion innecesaria y que priva al programa de la posibilidad deejecutarse en sistemas distribuidos. Los buzones en sı se suelen declarar en el programaprincipal, es decir, estan declarados de forma global, pero no se considera que seanvariables globales, sino mecanismos de comunicacion. Por esa razon, el mero hecho deusar buzones no significa utilizar memoria compartida.

Conviene recordar que los buzones son herramientas bloqueantes. Si un proceso inten-ta leer de un buzon vacıo, quedara bloqueado hasta que otro proceso escriba en dichobuzon. Una forma de evitar esta situacion es usar adecuadamente la funcion EMPTY. Siel buffer es de tamano finito, las operaciones de escritura en el buzon tambien provocanbloqueo cuando el buffer asociado este lleno. Una excepcion a ambas situaciones es eluso de la sentencia SELECT.

Otro error comun, quizas influencia de la herramienta canales, es usar un buzon distintopor cada dos procesos que quieran comunicarse entre ellos. Un mismo buzon puede serutilizado por todos los procesos. Un ultimo error comun es olvidar que la comunicacionen los buzones puede ser bidireccional. Un proceso puede utilizar un mismo buzon tantopara leer como para escribir en el.

Tema 8 Invocacion remotaLa herramienta conocida como rendez-vous, cita de Ada o invocacion remota se explicaen el capıtulo 10 del texto base, en las secciones 10.1 (introduccion) y 10.2 (invocacionremota).

La invocacion remota es la herramienta de mas alto nivel conceptual de todas las herra-mientas 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 concurrentemas claramente enfocada al desarrollo de aplicaciones cliente-servidor.

Una diferencia sustancial de la invocacion remota respecto a cualquier otra herramientade PC, es que el que uso de invocacion remota suele llevar parejo el uso de procesos adi-cionales que actuan como servidor o controlador. En particular, la simulacion de otrasherramientas de sincronizacion mediante invocacion remota implica la creacion de nue-vos procesos. A este respecto, la simulacion de un semaforo mediante invocacion remotaen 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 posiblementeconveniente, utilizar la invocacion remota sin usar memoria compartida. En ese caso lacuestion ni se plantea. Si se combina memoria compartida e invocacion remota puedehaber problemas, especialmente si tenemos en cuenta que la invocacion remota permiteel paso de parametros en ambas direcciones entre el proceso llamador y el llamado. Elpaso de parametros implica copia de los mismos, por lo que si se pasan como parametrosde una invocacion remota variables compartidas, los resultados pueden ser impredeci-bles.

8.4. Bloque tematico 3: Problemas de aplicacion

En PC hay dos problemas-tipo cuyo conocimiento es absolutamente imprescindible: Setrata del problema de los lectores y escritores y del problema de los productores y consumido-res. Multitud de los aspectos de colaboracion entre los procesos de un programa concurrenteresponden a alguno de estos esquemas, ya sea directamente o mediante variaciones, combi-naciones o generalizaciones de los mismos. Solo por este motivo su incorporacion al temarioestarıa sobradamente justificada, pero ademas, el estudio de su resolucion mediante las dife-rentes herramientas del segundo bloque tematico supone una excelente manera de comprendersu funcionamiento en la practica.

Por otra parte, es logico suponer que tambien hay problemas que no responden en absolutoa dichos esquemas algorıtmicos. El otro problema resuelto en el texto base usando todas lasherramientas de sincronizacion es el problema de la comida de los filosofos. Se trata de unproblema clasico propuesto por Andrew Tanembaum para ilustrar muchos de los problemasque se producen al intentar solucionar un problema de PC de apariencia inocente, pero que notiene 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 identificarun 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 unico tema:

23

9 Actividades

Tema 10 Problemas de aplicacion

Los problemas de aplicacion pueden estudiarse en las siguientes secciones del textobase: 4.3 (resolucion de problemas usando semaforos), 5.3 (resolucion de problemasusando RCC), 6.4 (resolucion de problemas usando monitores), la 8.2 (resolucion deproblemas empleando paso de mensajes asıncrono) y 10.3 (resolucion de problemasmediante 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 tendrıa poco sentido, tambienhabra procesos que intenten modificarlo. La primera restriccion descarta el acceso enexclusion mutua al recurso. La segunda descarta el acceder al recurso compartido sinningun tipo de sincronizacion. El esquema algorıtmico de los lectores y escritores es uningenioso mecanismo que permite satisfacer ambas restricciones al mismo tiempo. Eltexto base trata la cuestion desde un punto de vista bastante teorico. Como la division encapıtulos se realiza en funcion de las diferentes herramientas, los problemas resueltos ypropuestos al final de cada capıtulo suelen restringirse a proponer problemas de ındolegeneral de cada herramienta concreta. En el curso virtual puede encontrarse una ciertacantidad de examenes resueltos que enfocan los problemas-tipo.

En la implementacion de lectores y escritores con preferencia para la escritura resueltomediante semaforos, en la pagina 101 del texto base, hay una errata: Donde pone ”ne :=ne -1;”, deberıa poner ”escribiendo := false”.

El problema-tipo de los productores y consumidores suele provocar menos problemas decomprension que el de los lectores y escritores, por lo que se recomienda al estudianteque intensifique su estudio de este segundo.

El problema de la cena de los filosofos no es un problema-tipo, sino mas bien el tipode 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-tipode los filosofos es un hecho bizarro que se recomienda evitar.

9. Actividades

En el texto base y la bibliografıa complementaria pueden encontrarse numerosos ejerciciospropuestos y resueltos. Del mismo modo, en el curso virtual pueden encontrarse practicas yexamenes de otros anos, algunos de ellos resueltos.

24