Sistemas Operativos Mod7

7/23/2019 Sistemas Operativos Mod7

1/52

La concurrencia

y la comunicacinDolors Royo Valls

P05/75097/00810Mdulo 7


2/52


3/52

FUOC P05/75097/00810 Mdulo 7 La concurrencia y la comunicacin

ndice

Introduccin............................................................................................. 5

Objetivos .................................................................................................... 6

1. Introduccin a la concurrencia y a la comunicacin

de procesos ........................................................................................... 7

2. La sincronizacin de procesos......................................................... 9

2.1. Para qu es necesaria la sincronizacin? ....................................... 9

2.2. La seccin crtica ............................................................................. 13

3. Las soluciones de softwarepara la exclusin mutua ................ 16

3.1. Primer algoritmo.............................................................................. 16

3.2. Segundo algoritmo .......................................................................... 17

3.3. Tercer algoritmo .............................................................................. 18

3.4. La ejecucin mutua de ms de dos procesos................................... 19

4. Los semforos ...................................................................................... 20

4.1. Definicin de semforo ................................................................... 20

4.2. La utilizacin de los semforos........................................................ 21

4.3. Las caractersticas de los semforos................................................. 23

4.4. La implementacin de los semforos.............................................. 24

5. El soporte de hardwarepara la exclusin mutua...................... 26

5.1. La inhibicin de las interrupciones................................................. 26

5.2.Test and set....................................................................................... 27

5.3. El intercambio (swap) ...................................................................... 28

6. Ejemplo: procesos productores y consumidores......................... 30

7. La comunicacin entre procesos. El paso de mensajes ............. 36

7.1. La implementacin de los mensajes ............................................... 36

7.1.1. Los mensajes directos y los indirectos ................................. 37

7.1.2. La comunicacin sncrona y asncrona ............................... 38

7.1.3. La longitud de los mensajes ................................................. 39

7.2. La exclusin mutua mediante mensajes ......................................... 39

8. Los problemas de coordinacinentre procesos (deadlock) ................................................................. 40


4/52

FUOC P05/75097/00810 Mdulo 7 La concurrencia y la comunicacin

Resumen..................................................................................................... 43

Actividades................................................................................................ 45

Ejercicios de autoevaluacin................................................................ 45

Solucionario.............................................................................................. 48

Glosario...................................................................................................... 51

Bibliografa............................................................................................... 51


5/52

FUOC P05/75097/00810 Mdulo 7 5 La concurrencia y la comunicacin

Introduccin

En el mdulo didctico que ahora empezamos se estudiarn los procesos con-currentes y cooperativosque comparten un conjunto de recursos del siste-

ma. Bsicamente, estos recursos son los dispositivos, el cdigo y las variables

compartidas.

La sincronizacin de los procesoses absolutamente necesaria para asegurar

las relaciones de precedencia y para evitar problemas de temporizacin rela-

cionados con la existencia de procesos concurrentes.

Debido a que el sistema operativo no conoce la semntica de las actividades de

los procesos, el programador se encarga de asegurar que la sincronizacin se lle-

ve a cabo de manera correcta. Para ayudar a los programadores en esta tarea, los

sistemas multiprogramados y los lenguajes de programacin ofrecen una serie

de herramientas para establecer tanto la sincronizacin como el intercambio de

informacin entre todos los procesos concurrentes y cooperativos.


6/52


Objetivos

En los contenidos didcticos de este mdulo, encontraris las herramientasbsicas para alcanzar los siguientes objetivos:

1. Saber que la comparticin de recursos del sistema (los dispositivos, el cdi-

go, las variables compartidas, etc.) da lugar a la necesidad de sincronizar los

procesos que los comparten para garantizar que el acceso de los procesos a

estos recursos se efecta correctamente (en exclusin mutua).

2. Conocer las ventajas e inconvenientes de los diferentes mecanismos que

ofrece un sistema para garantizar el acceso en exclusin mutua a los recur-

sos compartidos. Y esto implica:

Entender la dificultad que supone el hecho de generalizar las soluciones de

softwarepara garantizar el acceso en exclusin mutua de diferentes proce-

sos a los recursos compartidos.

Conocer la potencia de los mecanismos de softwarey los peligros que implica

el hecho de dejarlos en manos de los programadores.

Saber que los mecanismos ms apropiados desde el punto de vista de la efi-ciencia, la facilidad de uso y la seguridad del sistema son aquellos que com-

binan los mecanismos de softwarey hardware: los semforos.

Ser conscientes de la necesidad de sincronizar y comunicar los procesos

que cooperan de manera concurrente para cumplir una tarea comn.

Saber que todas las herramientas que sirven para asegurar el acceso exclu-

sivo a los recursos del sistema son difciles de utilizar y que hay que tener

mucho cuidado para no provocar situaciones inconsistentes o bloqueado-

ras cuando se trabaja con ellas.


7/52


8/52


b) La memoria compartida, que comunica procesos mediante el uso de va-

riables compartidas.

c) Las seales, interrupciones de softwareque pueden recibir los procesos para

indicar que se ha producido un determinado suceso; por ejemplo, que ha fi-

nalizado un temporizador, que se ha producido una bajada de tensin, que se

ha generado una salida de rango en operaciones aritmticas (overflow), etc.

d) Los mecanismos de comunicacin remota(sockets).

Podis ver las seales en el apartado3 del mdulo didctico La gestinde procesos.


9/52


2. La sincronizacin de procesos

El uso de variables compartidas es una manera bastante habitual de comuni-cacin que utilizan los procesos dentro del sistema. En este apartado se vern

los problemas que surgen cuando varios procesos comparten un objeto del sis-

tema, ya sea una variable, una fragmento de cdigo o un dispositivo. Se pro-

pondrn varias soluciones de softwarey hardware, y tambin analizaremos la

eficacia y la viabilidad de cada una a la hora de asegurar accesos concurrentes

a objetos compartidos.

2.1. Para qu es necesaria la sincronizacin?

Veamos para qu es necesaria la sincronizacin de los procesos con la ayuda

de un caso concreto. Un ejemplo claro de variable compartida es el de una va-

riable contador, que denominaremos tarea_pendiente, y que se ve modifi-

cada por varios procesos (usuario y gestor); tenemos que:

a) Los diferentes procesos usuario que se estn ejecutando concurrentemente

en el sistema la actualizan (la incrementan) cada vez que se enva una tarea* a

la impresora. As, esta variable compartida indica cuntas tareas pendientes de

impresin hay en el sistema.

b) El proceso gestor de la impresora enva las tareas a imprimir y actualiza el valor

del contador decrementndolo cada vez que finaliza la impresin de una tarea.

Si la actualizacin de esta variable contador se efecta sin ningn tipo de res-

triccin, se pueden generar inconsistencias, es decir, resultados errneos. En

el caso de nuestro ejemplo, estos resultados errneos podran repercutir en el

proceso de impresin de manera que se podra dejar de imprimir alguna tarea,

o bien intentar imprimir alguna que no existiese.

Veamos cmo se pueden generar estas inconsistencias analizando nuestro

ejemplo:

a) Como ya hemos indicado antes, un proceso usuarioa la hora de enviar

una tarea a imprimir incrementa la variable tarea_pendiente, y lo hace me-

diante el siguiente cdigo:

{Cdigo del proceso usuario}

...

tarea_pendiente = tarea_pendiente + 1

...

* Las tareas que los procesosusuario envan a la impresora

son ficheros.


10/52


b) El proceso gestor de la impresoracada vez que finaliza la impresin de un

trabajo decrementa la variable tarea_pendiente mediante el cdigo que

presentamos a continuacin:

As pues, la variable compartida tarea_pendienteindica cuntas tareas se

encuentran pendientes de ser enviadas a la impresora.

El principal problema que se plantea con el cdigo que acabamos de presentar,y en general con el cdigo programado en cualquier lenguaje de alto nivel, es

que, durante la compilacin del programa, una instruccin de alto nivel se tra-

duce en una o ms instrucciones de lenguaje mquina.

De este modo, por ejemplo, en una mquina RISC (Reduced Instruction Set

Computer), el cdigo que se genera tras haber compilado el cdigo de nuestro

ejemplo podra ser ste:

a) En el caso del cdigo del proceso usuario, nos encontramos con lo si-guiente:

b) En el caso del cdigo del proceso gestor de la impresora, podemos encon-

trar lo siguiente:

Los detalles de la codificacin carecen de importancia, lo que nos interesa

apreciar aqu es que durante la ejecucin de la instruccin de alto nivel para

incrementar/decrementar la variable tarea_pendientese hacen copias tem-

porales del contenido en registros del sistema*. Estas copias locales, como las

{Cdigo del proceso gestor de la impresora}...

tarea_pendiente = tarea_pendiente 1

...

LOAD R0, tarea_pendiente ;Copiar el contenido de tarea_pendiente en el registro R0

INC R0 ;Incrementar R0

STORE tarea_pendiente, R0 ;Almacenar R0 en tarea_pendiente

LOAD R1, tarea_pendiente ;Copiar el contenido de tarea_pendiente en el registro R1

DEC R1 ;Decrementar R1

STORE tarea_pendiente, R1 ;Almacenar R1 en tarea_pendiente


11/52


que se hacen en los registros R0y R1, pueden resultar inconsistentes con el va-

lor de la variable de la memoria en un instante determinado de la ejecucin

del proceso. Esta inconsistencia es la que puede llevar a las dos situaciones

errneas mencionadas:

1) No impresin de una tarea

Consideraremos, por ejemplo, que la variable tarea_pendientetiene un va-

lor inicial igual a 3 cuando el gestor de la impresora ejecuta las instrucciones

en lenguaje mquina que se han especificado anteriormente de la siguiente

manera:

a) En primer lugar, hace una copia del valor de la variable en el registro R1. El valor

de R1coincide en este momento con el valor de la variabletarea_pendiente, 3.

b) A continuacin, decrementa el valor del registro, que pasa a valer 2. Ahora

el valor de la copia es diferente del valor de la variable tarea_pendienteen

la memoria, 3, motivo por el cual se da una inconsistencia.

Si en este punto de la ejecucin del cdigo mquina le ocurre algo al sistema*

que hace que el proceso gestor deje de ejecutarse, el sistema queda inconsis-

tente.

En este estado de inconsistencia, lo peor que puede pasar es que un proceso

usuario intente enviar una tarea a imprimir. En tal caso, cuando el proceso

quiere incrementar el valor de la variable tarea_pendiente, pasa lo que aho-

ra presentamos:

a) Se hace una copia de la variable en el registro R0, y R0vale 3, puesto que

la variable tarea_pendientecontina teniendo el valor 3, ya que el gestor

no la haba actualizado.

b) Se incrementa el valor del registro R0, que pasa a valer 4.

* Los registros del sistema sonregistro de hardware, y no tienenque ser necesariamente diferentes

para cada copia temporal.

Lneas de cdigo Variable contador Registros

Proceso en espera Proceso activo tarea_pendiente R0 R1

... ... 3 ... ...

LOAD R0, tarea_pendiente LOAD R1, tarea_pendiente 3 ... 3

INC R0 DEC R1 3 ... 2

STORE tarea_pendiente, R0 STORE tarea_pendiente, R1

... ...

* Un cambio de contexto porqueexpira el quantum del proceso

gestor, una interrupcinde un dispositivo, una bajada

de tensin, etc.


12/52


c) Se actualiza la variable tarea_pendiente, que pasa a valer 4.

Al cabo de un tiempo, cuando el proceso gestor se vuelve a ejecutar, puesto que

se haba interrumpido justo cuando tena que ejecutar la instruccin STORE, lo

primero que ejecuta es STORE tarea_pendiente, R1. El valor de R1en el pro-

ceso gestor era 2, de modo que el valor de la variable tarea_pendienteen la

memoria se actualiza y pasa a ser 2.

Despus de esta secuencia de operaciones, el valor de tarea_pendienteno es

correcto. Habamos partido de un valor de 3, el proceso gestor lo ha decremen-tado una vez y un proceso usuario lo ha incrementado otra vez. As, el valor fi-

nal de la variable tendra que ser 3 y, en cambio, lo que hemos conseguido es

asignarle un valor igual a 2.

A efectos prcticos, en el sistema nos encontramos con un trabajo que no se

imprimir.

2) Intento de impresin de un trabajo no existente

El caso simtrico al anterior es aqul en el que el usuario inicia la operacin de

actualizacin de la variable y no la finaliza porque es interrumpido. Este pro-

ceso implica que el valor final de la variable considerada, tarea_pendiente,

sea errneo e igual a 4.



... ... 3 ... 2

STORE tarea_pendiente, R1 LOAD R0, tarea_pendiente 3 3 2

INC R0 3 4 2

STORE tarea_pendiente, R0 4 4 2

...



... ... 4 4 2

... STORE tarea_pendiente, R1 2 4 2

...



... ... 3 ... ...

LOAD R1, tarea_pendiente LOAD R0, tarea_pendiente 3 3 ...

DEC R1 INC R0 3 4 ...STORE tarea_pendiente, R1 STORE tarea_pendiente, R0

... ...


13/52


En este caso, el gestor de la impresora intentara enviar a imprimir un trabajo

que no existe.

Todos los procesos se habran ejecutado correctamente si las operaciones de

incremento y decremento que el programador escribe en el lenguaje de alto

nivel se hubiesen ejecutado de manera indivisible o atmica. La indivisibili-

dad a la hora de ejecutar estas operaciones nos asegura, a efectos prcticos, que

cuando un proceso incrementa/decrementa, la variable no deja el procesadorhasta que no ha finalizado la actualizacin o, dicho de otro modo, una vez se

ha inicializado una operacin de actualizacin de una variable compartida,

ningn proceso podr iniciar otra operacin de actualizacin de aquella varia-

ble hasta que no haya finalizado la primera.

Mediante este ejemplo se demuestra que la ejecucin concurrente no sincroni-

zada de procesos que utilizan variables compartidas puede dar lugar a errores

irrecuperables.

2.2. La seccin crtica

Ante la posibilidad de generar resultados no coherentes e incorrectos durante la

ejecucin concurrente de procesos con variables compartidas, es absolutamente

necesario encontrar alguna solucin. Antes de hacer alguna propuesta, veamos

cul es el problema real que nos encontramos en el funcionamiento descrito en

el ejemplo anterior. Como hemos podido comprobar, la aparicin de copias

temporales y la posibilidad de que un proceso acceda al contenido de una varia-

ble compartida en cualquier instante antes de asegurarse de que todas las peti-

ciones de modificacin previas han finalizado son las principales causas de

todos los males.



... ... 3 4 ...

STORE tarea_pendiente, R0 LOAD R1, tarea_pendiente 3 4 3

... DEC R1 3 4 2

STORE tarea_pendiente, R1 2 4 2

...



... ... 2 4 2

... STORE tarea_pendiente, R0 4 4 2

...


14/52


Cuando un proceso entra en una seccin crtica, tiene que completar todas las

instrucciones del interior de la seccin antes de que cualquier otro proceso

pueda acceder a sta. De esta manera se garantiza que las variables comparti-

das que se modifiquen dentro de la seccin slo son modificadas por un nico

proceso a la vez. Este tipo de procedimiento se denomina acceso a la seccin

crtica en exclusin mutua, y garantiza que hasta que un proceso no finaliza

la modificacin de la variable compartida, ningn otro proceso puede empe-

zar a modificarla*.

La solucin al problema del acceso en exclusin mutua a variables y dispositi-vos compartidos en el sistema tiene que cumplir los siguientes requisitos:

a) Asegurar la exclusin mutua entre los procesos a la hora de acceder al re-

curso compartido.

b) No hacer ningn tipo de suposicin de la velocidad de los procesos ni del

orden en que se ejecutarn para asegurar un buen funcionamiento del sistema.

c) Garantizar que si un proceso finaliza por cualquier razn dentro de la zona

de exclusin mutua, no afectar al resto de procesos que estn interesados en

acceder a la seccin crtica.

d) Permitir que todos los procesos que se estn esperando para entrar en la

seccin crtica puedan hacerlo en un tiempo finito (starvation).

e) Garantizar que como mximo uno de los procesos que quieren acceder a la

seccin crtica acabe entrando (deadlock).

La forma ms sencilla de asegurar la exclusin es no permitir la concurrenciade procesos. Sin embargo, esta solucin es inaceptable, puesto que lo que nos

interesa es determinar protocolos y herramientas de acceso a las secciones que

cumplan los requisitos que hemos enumerado.

En la mayor parte de las estrategias propuestas para garantizar la exclusin

mutua, los procesos siguen el siguiente protocolo:

La actualizacin de una variable compartida se puede considerar una

seccincrtica, es decir, una secuencia bien delimitada (con inicio y

fin) de instrucciones que modifican una o ms variables compartidas.

/*Peticin de acceso a la seccin*/

seccin crtica/*Liberar la seccin*/

* Es decir, se efecta estrictamentede manera secuencial.


15/52


Antes de acceder a la seccin crtica, todos los procesos formulan una peticin

de acceso; entonces:

1) Si la seccin crtica est ocupada por otro proceso, se pueden esperar blo-

quendose* o bien llevando a cabo una espera activa**.

2) Si la seccin crtica est libre, entrarn, de modo que cierran el acceso a cual-

quier otro proceso que est interesado en entrar. Una vez dentro, utilizan el re-

curso compartido y cuando lo han utilizado, liberan la exclusin mutua para

que otros procesos puedan utilizarlo.

As pues, se han propuesto diferentes estrategias para efectuar el acceso y la li-

beracin de recursos en exclusin mutua. En el siguiente apartado definiremos

algunas estrategias de software. Despus describiremos los semforos, una es-

trategia eficiente y fcil de utilizar y, por ltimo, se presentarn algunas tcni-

cas de hardwareque permiten la exclusin mutua y que en general se utilizan

para implementar otras herramientas de softwarede nivel ms alto, como los

semforos.

* Durmindose, ponindoseen alguna cola de espera.

** Consultado continuamenteel estado del recurso.


16/52


3. Las soluciones de softwarepara la exclusin mutua

El problema de la exclusin mutua no es sencillo. A continuacin se proponensoluciones de softwarepara sincronizar los procesos a la hora de acceder a re-

cursos compartidos. El anlisis de las siguientes propuestas nos permitir con-

siderar algunos problemas importantes que se deben tener en cuenta al utilizar

un algoritmo de sincronizacin.

3.1. Primer algoritmo

Este primer algoritmo sirve para sincronizar dos procesos,P0y P1. Se define unavariable global que denominamos turno, mediante la cual se indica en todo mo-

mento qu proceso tiene acceso a la zona crtica. Siturnoes igual a P0, el proceso

P0puede acceder a la seccin; si turnoes igual aP1, entonces el procesoP1puede

acceder a la seccin. Supongamos que la variableturnose inicializa en P0.

a) El proceso P0ejecuta el siguiente cdigo:

b) El proceso P1ejecuta el cdigo complementario que ahora presentamos:

Esta primera solucin asegura la exclusin mutua de los recursos compartidos

(el cdigo, los dispositivos, etc.), pero presenta los problemas siguientes:

1) Hay que conocer los procesos. Esto comporta que esta informacin se pue-

da utilizar de manera indebida*.

while (cierto) {/*Bucle infinito*/

while (turno == P1) {intentarlo de nuevo}seccin crtica

turno = P1

/*Otras operaciones de P0*/

} /*Fin while (cierto)*/


while (turno == P0) {incrementarlo de nuevo}

seccin crtica

turno = P0



* Se pueden dar problemasde proteccin de la integridad

de los procesos.


17/52


2) Es difcil generalizar el protocolo de sincronizacin para un nmero varia-

ble de procesos debido a que cada proceso tiene que saber a quin debe ceder

el turno. El hecho de aadir o quitar procesos supone modificar el cdigo de

otros procesos que ya existan.

3) El protocolo de sincronizacin obliga a una alternancia estricta en el accesoal recurso por parte de los procesos. En el ejemplo, los procesos acceden a la

zona crtica con el siguiente orden: P0,P1,P0,P1, etc. Este esquema puede ser

totalmente ineficiente en caso de que los recursos no sean simtricos, es decir,

que tengan velocidades de trabajo diferentes. Si, por ejemplo, el procesoP0fue-

se el doble de rpido que el proceso P1, sera ms conveniente un patrn de ac-

ceso P0,P0,P1,P0,P0,P1, etc.

4) Si uno de los dos procesos aborta o muere por alguna causa, qu ocurre

con el otro proceso? Con el esquema que hemos aplicado, el otro proceso no

podr acceder a la seccin crtica y se quedar de manera indefinida esperando

en el bucle while (turno = Px). El problema puede ser todava ms grave

en caso de que el proceso aborte o muera dentro de la seccin crtica, y sta es

la del proceso gestor de un dispositivo.

3.2. Segundo algoritmo

Este algoritmo se construye a partir del anlisis efectuado en el algoritmo ante-

rior. Para evitar la alternancia estricta en el acceso de los procesos a la zona cr-tica que provocaba el algoritmo anterior, definiremos dos variables:P0dentro

y P1dentro. Cada proceso modificar su identificador (cierto/falso) para

mostrar las intenciones respecto del recurso compartido. Antes de entrar en la sec-

cin, observa si sta se encuentra ocupada por otro proceso. En un principio, am-

bos indicadores toman el valor falso.


b) El proceso P1ejecuta el cdigo complementario que ahora presentamos:

while (cierto) {/*Bucle infinito*/while (P1dentro == cierto) {intentarlo de nuevo}

P0dentro = cierto

seccin crtica

P0dentro = falso





18/52


Este nuevo algoritmo soluciona algunos de los problemas que encontrbamos

en el primer algoritmo y, adems, presenta las siguientes ventajas:

No se da alternancia en el uso de los recursos.

Si un proceso aborta o muere por cualquier motivo, el otro proceso puede

acceder a la seccin crtica sin ningn tipo de restriccin.

Sin embargo, sigue encontrndose con estos problemas:

1) Tambin es difcil de generalizar para un nmero variable de procesos.

2) Podra ser que en un instante de tiempo ambos procesos estuviesen dentro

de la seccin crtica. Consideraremos el caso de que los dos procesos se hallanfuera de la seccin y las variables P0dentroy P1dentroindican que el recur-

so est libre. El proceso P0observa a P1dentroy ve que est a falso. Antes

de modificar la variable P1dentroy colocarla a cierto, el proceso P1consul-

ta P0dentroy tambin la encuentra a falso. A partir de este instante, ambos

procesos pueden acceder a la zona crtica.

Resulta fcil comprobar que mediante el intercambio de las instrucciones

Pxdentro = cierto y while(Pydentro == cierto) en el cdigo que se

tiene que ejecutar tampoco se soluciona nada. En este caso se asegura la exclu-

sin mutua, pero los procesos pueden quedarse de manera indefinida en el bucle

sin que su ejecucin progrese.

3.3. Tercer algoritmo

Combinando las ideas de los dos algoritmos que se han presentado hasta aho-

ra, a continuacin se propone un algoritmo nuevo que s que cumple todos

los requisitos indispensables para tener un buen funcionamiento. En este ca-so, nos encontramos con dos variables por proceso: P0dentro y turno, y

P1dentroy turno. Las variables P0dentroy P1dentrose inicializan a falso,

while (P0dentro == cierto) {intentarlo de nuevo}

P1dentro = cierto

seccin crtica

P1dentro = falso




19/52


y no es necesario inicializar la variable turno. Veamos el cdigo de los proce-

sos para entender su funcionamiento:


b) El proceso P1ejecuta el cdigo complementario que ahora mostramos:

Si ambos procesos quieren entrar en la zona crtica al mismo tiempo, entrar

el que indique la variable turno.

3.4. La ejecucin mutua de ms de dos procesos

Los algoritmos descritos en este apartado slo tienen en cuenta dos procesos.

Podemos encontrar otras propuestas para sincronizar ms de dos procesos,

pero son muy cargantes y, en consecuencia, complicadas de entender. Es im-

portante conocer su existencia, pero no vale la pena hacer el esfuerzo de in-

tentar describirlas y entender su funcionamiento, ya que existe un mtodo

mucho ms elegante y sencillo para resolver el problema: los semforos, que

describimos a continuacin.


P0dentro = cierto

turno = P1

while (P1dentro == cierto and turno == P1) {intentarlo

de nuevo}

seccin crtica

P0dentro = falso




P1dentro = cierto

turno = P0

while (P0dentro == cierto and turno == P0) {intentarlo

de nuevo}seccin crtica

P1dentro = falso



Lectura complementaria

En la bibliografa indicadaencontraris algoritmos quegarantizan la sincronizacinen ejecucin concurrentede ms de dos procesos.A. Silberschatz; J. Peterson;P. Galvin(1994). Sistemasoperativos, conceptosfundamentales(3. ed.; trad.de E. Morales). Argentina:Addison-Wesley

Iberoamericana.


20/52


4. Los semforos

Los algoritmos que se han propuesto en la literatura para asegurar la exclusinmutua de una seccin crtica son complejos y a menudo difciles de generali-

zar para ms de dos procesos. Una solucin a este problema son los semforos.

4.1. Definicin de semforo

Un semforo se define como una variable entera Sque, dejando a un lado la

inicializacin, slo se puede modificar (incrementar/decrementar) mediante

dos operaciones, que reciben el nombre de signal(sealar) y wait(esperar).

Estas operaciones tienen que ser atmicas para que su funcionamiento sea co-

rrecto. La variable Sse pasa como parmetro en las dos operaciones, las cuales

se definen de la siguiente manera:

wait(S)decrementa el valor de la variable Sy hace pasar el proceso a la

seccin crtica cuando Ses mayor que 0. Mientras el valor de Ssea menor

o igual que cero, el proceso espera.

signal(S) incrementa el valor de la variable S.

Podemos diferenciar los dos tipos de semforos que exponemos a continua-

cin:

1) Los semforos binarios, que slo pueden tomar los valores 0 y 1, y nica-

mente permiten tener un proceso dentro de la seccin crtica.

2) Los semforos n-arios, que son aquellos que pueden tomar valores desde

0 hasta n, y permiten tener hasta nprocesos dentro de la seccin crtica.

Los semforosconstituyen una herramienta de sincronizacin que per-

mite garantizar la exclusin mutua de una seccin crtica entre un n-

mero arbitrario de procesos de forma limpia y sencilla.

While (S


21/52


4.2. La utilizacin de los semforos

Acto seguido nos disponemos a presentar un esquema que sirve para imple-

mentar semforos binarios o n-arios en funcin de si se inicializa a 1 en el caso

de los binarios, o a n, en el de los n-arios.

Para asegurar el acceso a la seccin crtica en exclusin mutua hay que utilizar

los semforos de la siguiente forma:

1) Se inicializa el semforo(S >= 0). El valor inicial del semforo tiene que ser

mayor o igual que 1 para indicar que no hay ningn proceso dentro de la seccin

crtica, y de esta manera dejar paso al primer proceso que, mediante la operacin

wait, solicite permiso para entrar. Puede darse el caso de que el semforo se ini-

cialice a 0, con esto se consigue que el proceso que pide acceso a la seccin crtica

se quede bloqueado.

2) Se ejecuta la operacinwait. El proceso que quiere acceder a una zona

compartida en exclusin mutua ejecuta la funcin wait sobre el semforo

asociado a la seccin. La granularidad de un semforoindica el nmero de

zonas crticas a las que se encuentra asociado.

Distinguiremos dos grados de granularidad:

Granularidad baja. Comporta tener semforos diferentes para zonas crticas

diferentes, lo cual aumenta el grado de concurrencia entre los diferentes pro-

cesos concurrentes. En general interesa tener este grado de granularidad.

Granularidad alta.Se da cuando se utiliza un mismo semforo para ase-

gurar la exclusin de diferentes zonas crticas (independientes entre s).

3) Se ejecuta la operacinsignal. El proceso que ha finalizado la ejecucin

de la zona crtica libera la exclusin y permite el paso a otros procesos.

Veamos cul sera el cdigo de los procesos usuario y del proceso gestor de laimpresora en caso de que stos utilicen semforos para actualizar la variable

compartida tarea_pendiente.

En un principio, el sistema inicializa la variable semforo exclusion, me-

diante el uso de este cdigo:

/*Definicin de la variable e inicializacin*/

Variable semforo: exclusin;

...

exclusion = 1; /*Inicializacin*/


22/52


a) Consideramos que el cdigo de un proceso usuarioes el siguiente:

b) Consideramos que el cdigo del proceso gestor de la impresoraes ste:

Para ilustrar el comportamiento y el funcionamiento de los semforos, mos-

tramos a continuacin un posible escenario de ejecucin de tres procesos

usuarios (P1,P2,P3) y el proceso gestor (G1). Las diferentes columnas indican

qu acciones lleva a cabo cada uno de los procesos en cada unidad de tiempo,

qu procesos estn esperando al semforo, qu proceso se encuentra dentro de

la seccin crtica y cul es el valor del semforo en cada instante concreto. (Ob-

servad la tabla de la pgina siguiente.)

Supondremos que el semforo, exclusion, se ha inicializado a 1 y que los

procesos usuario y el proceso gestor se encuentran dentro del bucle infinito.

Los procesos usuario generan continuamente trabajos, que se envan a la im-

presora, y el proceso gestor imprime continuamente los trabajos que han ge-

nerado los procesos usuario.

En la tabla podemos ver que en el tiempo T0se inicializa la variable semforo y

todava no se ha creado ningn proceso; no hay ningn trabajo pendiente de

impresin. En T1, la variable semforo exclusionha decrementado su valor

hasta 0, lo cual indica que un proceso ha recibido el permiso para entrar en la

seccin crtica, que en este caso ha sido el proceso usuarioP1. El resto de los pro-

cesos, el gestor y los usuarios, estn intentando entrar en la seccin, pero el me-

/*Cdigo de los procesos usuario*/

...

while(cierto){/*Generar fichero*/

wait(exclusion);

tarea_pendiente = tarea_pendiente + 1;

signal(exclusion);

} /*Fin del while*/

/*Cdigo del proceso gestor de la impresora*/

...

while(cierto){

while(tarea_pendiente == 0);

/*Enviar trabajo a la impresora*/

wait(exclusion);

tarea_pendiente = tarea_pendiente 1;

signal(exclusion);



23/52


canismo del semforo asegura que ningn otro proceso puede entrar hasta que

P1no lo libere mediante la ejecucin de la operacin signal(exclusion).

Supongamos que los tres procesos usuario generan los ficheros correspondien-

tes y, como se ha indicado en el cdigo del proceso usuario, a continuacin

examinamos el valor del semforo exclusioncon la intencin de decremen-

tar su valor y entrar en la seccin crtica (modificar la variable). Uno de los trestiene xito, a pesar de que no podemos asegurar cul de ellos acabar entrando

en la seccin crtica*. En el ejemplo, la operacin waitque ejecuta P1, despus

de haber ledo el valor del semforo a 1, tiene que apropiarse de la variable se-

mforo y evitar que el resto de los procesos concurrentes (P2 yP3) pueda ac-

ceder a ella antes de que sea modificada (decrementada a 0). ste es el motivo

por el cual el cdigo de la operacin waitdebe ser invisible. Ms adelante ve-

remos cmo podemos solucionar este problema.

Una vez dentro de la seccin crtica, el proceso P1actualiza la variable y, a conti-nuacin, libera la seccin crtica ejecutando la operacinsignal (exclusion).

En este instante, P2, P3y el proceso gestor de la impresora tienen la misma pro-

babilidad de entrar en la seccin crtica. En el ejemplo, el proceso P3es el que lo

consigue. Se vuelven a repetir las mismas operaciones y cuando P3libera la sec-

cin, entra de nuevo P1, mientras que los procesos P2y el proceso gestor de la

impresora continan esperndose.

4.3. Las caractersticas de los semforos

En funcin de lo que hemos visto hasta ahora, los semforos son un mecanismo

fcil y muy til para sincronizar procesos concurrentes. Este mecanismo permi-

TiempoEstado de los procesos Semforo

1-Libre

0-Ocupado

Dentro: fuera(espera)

P1 P2 P3 G1

T0 ... ... ... ... 1 ... : ...

T1 wait wait wait wait 0 ... : P1, P2, P3, G1

T2 Seccin crtica Esperando Esperando Esperando 0 P1 : P2, P3, G1

T3 signal Esperando Esperando Esperando 1 ... : P2, P3, G1

T4Otras

operacionesEsperando Seccin crtica Esperando 0 P3 : P2, G1

T5 wait Esperando Seccin crtica Esperando 0 P3 : P2, G1, P1

T6 Esperando Esperando signal Esperando 1 ... : P2, G1, P1

T7 Seccin crtica EsperandoOtras

operacionesEsperando 0 P1 : P2, G1

T8 signal EsperandoOtras

operacionesEsperando 1

... : P2, G1

* Con este uso de los semforos,el orden de acceso de los

procesos en la seccin crticaes totalmente aleatorio.

Podis ver los problemas queplantea la divisin del cdigoque constituyen las operacionesen el subapartado 2.1. del presentemdulo didctico.


24/52


te una gran flexibilidad a la hora de crear y modificar procesos que tienen que

acceder a un recurso compartido, sin afectar a otros procesos ya existentes. Me-

diante el ejemplo presentado hemos podido ver que existe la posibilidad de

crear un nmero indefinido de procesos usuario sin que por eso tengamos que

modificar el cdigo del proceso gestor o los de los mismos usuarios.

Los semforos son una herramienta que se puede encontrar con facilidad como

recurso que ofrece el sistema operativo*, o bien formando parte de algunas li-

breras de lenguajes.

Si implementamos un semforo tal y como hemos explicado hasta ahora, ha-

ciendo una espera activa, pueden surgir problemas de competencia entre los

diferentes procesos que lo utilizan. As pues, en el ejemplo hemos mostrado

un caso en que los procesosP1y P3acceden a la seccin crtica, mientras que

los procesos P2y el gestor, no.

Podra suceder que algn proceso se quedase esperando indefinidamente y no

se le concediese nunca el acceso a la seccin crtica. En el ejemplo propuesto,

si esto ocurriese en el caso del gestor, los resultados podran ser bastante gra-

ves: por un lado, no se imprimira ningn trabajo y, por el otro, podramos

llegar a colapsar la memoria del sistema a causa de la cantidad de tareas pen-

dientes.

Es importante definir una disciplina de asignacin de turnos de entrada a la

seccin crtica, como pueden ser FIFO (First In, First Out) o por prioridades, que

asegure a los procesos que quieren acceder a ste un tiempo de espera finito.

4.4. La implementacin de los semforos

A continuacin proponemos una implementacin alternativa de los semfo-

ros, que en tiempo y recursos es ms cara que las que hemos visto hasta ahora

pero que permite tener un control sobre el orden de las peticiones de acceso ala zona crtica. Este control ofrece la posibilidad de elegir cul ser el prximo

proceso que entrar en la seccin.

La implementacin propuesta en un principio por las operaciones wait y

signalsupone una espera activa de los procesos para acceder a la seccin cr-

tica. De manera intuitiva, la espera activa supone una consulta continua de la

variable semforo para ver si su valor es mayor que 0.

Este esquema presenta los dos problemas siguientes:

1) Un proceso utiliza ciclos del procesador en un trabajo que no es til: la con-

sulta de una variable. Estos ciclos del procesador se podran dedicar a otros

procesos.

Podis ver el ejemplo con tresprocesos usuario y un procesogestor en el subapartado 4.2.de este mdulo didctico.

* Los semforos se puedenencontrar como llamadas al sistema

operativo.


25/52


2) Un proceso se puede quedar esperando indefinidamente su entrada en la

seccin crtica debido a que esta implementacin no permite ningn tipo de

control sobre los procesos que estn esperando.

Estos problemas se solucionarn mediante la implementacin de los semfo-

ros con cola de espera:

El cdigo de las operaciones waity signalqueda de esta manera:

Operacin wait(S):

Operacin signal(S):

Como se puede apreciar, a cada semforo se le asigna una cola en la que los pro-

cesos pueden colocarse. Cuando un proceso solicita paso a la seccin crtica y sta

se encuentra ocupada, el proceso, en lugar de esperar activamente consumiendo

ciclos del procesador, suspende su ejecucin y se pone en la cola del semforo.

Cuando el proceso que estaba dentro de la seccin crtica la libera, antes de mo-

dificar la variable semforose da preferencia de acceso a los procesos que estn es-

perando en la cola. Siguiendo alguna poltica de asignacin (FIFO, prioridades,

tiempo de espera, etc.), elige un proceso, lo extrae de la cola de espera y lo pasa a

la cola de ejecucin. Si no hay ningn proceso esperando, incrementa el valor del

semforo para dejar la puerta de la seccin crtica abierta al primer proceso que

solicite la entrada.

Los semforos son los servicios ms bsicos y sencillos que suelen ofrecer los sis-temas para sincronizar procesos. Asimismo, se pueden utilizar para implementar

herramientas de sincronizacin ms elaboradas como pueden ser los monitores.

If (S


26/52


5. El soporte de hardwarepara la exclusin mutua

Hemos podido comprobar que la sincronizacin es necesaria para conseguirque el acceso a la seccin crtica en exclusin mutua se realice de manera co-

rrecta. Tambin se ha visto que las soluciones de softwareson complicadas y

en absoluto triviales, y que los semforos son una herramienta bastante fcil

de utilizar que soluciona el problema de la sincronizacin de manera elegante

para cualquier nmero de procesos. Ahora bien, para implementar los sem-

foros es necesario asegurar la indivisibilidad en la ejecucin del cdigo de las

operaciones waity signal.

A continuacin nos disponemos a presentar soluciones de hardwarepara eje-cutar el cdigo de manera indivisible. Indirectamente esto nos permitir la im-

plementacin de los semforos.

5.1. La inhibicin de las interrupciones

En la mayor parte de los computadores hallamos instrucciones que ofrecen la po-

sibilidad de inhibir (deshabilitar) y desinhibir (habilitar) las interrupciones. Con

estas instrucciones, la implementacin de la exclusin mutua resulta trivial.

Hemos podido apreciar que el problema de la exclusin mutua en general ra-

dica en la desasignacin del procesador a un proceso en ejecucin cuando ste

est modificando una variable compartida, ya que entonces la actualizacin

de esta variable queda a medio hacer. El procesador necesita las interrupciones

para ejecutar los diferentes procesos de manera concurrente. Si un proceso

desactiva las interrupciones, ste siempre tendr asignado el procesador hasta

que no las vuelva a activar.

Con este funcionamiento se puede garantizar la exclusin mutua de una sec-cin crtica mediante el siguiente esquema:

Estas interrupciones son muy peligrosas si se hace un uso indebido o malin-

tencionado de las mismas, porque, al no permitir la ejecucin de ningn pro-ceso, podran hacer que el sistema llegase al caos con mucha facilidad. Por este

motivo, nos interesa que estas instrucciones no se encuentren al alcance de los

inhibir {desactivar las interrupciones}

seccin crtica

desinhibir {activar de nuevo las interrupciones}


27/52


programadores de aplicaciones; lo ms habitual es que se utilicen dentro del

sistema operativo.

En el caso de los semforos, podemos hacer uso de estas llamadas para asegurar

la indivisibilidad de la ejecucin de las funciones waity signal.

5.2. Test and set

La operacin test andsetest pensada para dar un soporte de hardwareal pro-

blema del acceso a la zona crtica en exclusin mutua, y est diseada expre-

samente para resolver conflictos de acceso a zonas crticas y asegurar que slo

un proceso pueda acceder a la vez a la seccin crtica.

La idea bsica es definir una variable de control (global para todos los pro-cesos) asociada a la seccin crtica* que determine si el acceso es posible o

no. La variable se inicializa a libre, e indica que el recurso compartido

est disponible. Cada proceso que quiere acceder al recurso ejecuta la ope-

racin test and set(TS) y le pasa por parmetro la variable de control asocia-

da al recurso.

Esta operacin se escribe:

y funciona comparando el valor de la variable con ocupado; si se encuentra a

libre, lo modifica a ocupado. Los bits de condicin se modifican para indi-

car el estado de la variable justo antes de ejecutar la operacin TS.

Un semforo con espera activa podra implementar la operacin utilizando TS

de la siguiente manera:

Supongamos que inicialmente Stiene el valor libre; pues bien, cuando els

primer proceso ejecuta waitsucede lo siguiente:

1) La instruccin TS Sobserva el estado de S, y puesto que Sest en libre

lo pasa a ocupado. La instruccin TSmodifica los flagspara indicar que Ses-

taba libre.

TS variable

wait : TS S

BNF wait

return

* Recordad que la seccin crtica esuna parte de cdigo asociado al uso

de un recurso compartido.


28/52


2) La instruccin BNF(Branch if Not Free) salta a la etiqueta waitsi el valor de

Sestaba en ocupado. En nuestro caso, puesto que est a libre, no salta, el

proceso retorna de la llamada waity, en consecuencia, se le asegura el recurso

compartido.

Si existen otros procesos que quieren acceder al recurso, cuando ejecuten la

operacin wait nos encontraremos con que:

1) La instruccin TS Sobserva el estado de S, y debido a que Sest a ocupado,

no se modifica la variable. La instruccinTSmodifica los flagspara indicar que S

estaba ocupado.

2) La instruccin BNFsalta a la etiqueta wait, ya que el valor de Sestaba a

ocupado. De esta manera, todos los procesos permanecen ejecutando el buclewait, esperando que alguien libere el recurso compartido y, para liberar el re-

curso compartido, lo nico que hay que hacer es poner a libreel valor de S.

El cdigo de la operacin signalque lo puede hacer es el siguiente:

Es importante sealar que el cdigo de la instruccin waitfunciona porque

la instruccin TSes indivisible, o porque mientras el hardwareejecuta el mi-crocdigo asociado a esta instruccin, las interrupciones estn inhibidas.

5.3. El intercambio (swap)

La instruccin swap intercambia el contenido de dos palabras de memoria

atmicamente, y se define tal y como indicamos a continuacin:

Si el lenguaje mquina ofrece una instruccin de intercambio (swap), enton-

ces la exclusin mutua se puede conseguir de la siguiente forma: definimos

una variable global que denominamos lock, la cual puede tomar los valores

ciertoo falso; la variable se inicializa a falso. Adems, cada proceso tiene

una variable local, que recibe el nombre clave, y que tambin puede tomar

los valores ciertoy falso.

signal: mov S, libre

swap (A, B) {temp = A;

A = B;

B = temp;

} /*Fin swap*/


29/52


Todo proceso que quiere acceder a una zona crtica en exclusin mutua tiene

que ejecutar el siguiente cdigo:

while(cierto) {

clave = ciertodo

swap(lock, clave)

until {clave = falso}

seccin crtica

lock = falso

} /*Fin while(cierto)*/


30/52


6. Ejemplo: procesos productores y consumidores

El problema que pretendemos resolver se podra formular en los siguientes tr-

minos: consideramos un grupo de procesos consumidores y productores que

se estn ejecutando de manera concurrente y que pueden producir y consumir

a diferentes velocidades. Queremos proponer un protocolo de sincronizacin

que permita ejecutar los procesos tanto productores como consumidores con-currentemente a sus respectivas velocidades, y que los datos se consuman en

el mismo orden en que se han generado.

Todas las versiones propuestas para conseguirlo se basan en semforos. En

concreto, se presentan las tres versiones que se indican a continuacin:

1) Un productor y un consumidor con vector de memoria intermedia (buffer)

ilimitado.

2) Varios productores y varios consumidores con vectores de memoria inter-

media ilimitados.

3) Varios productores y varios consumidores con vectores de memoria inter-

media limitados.

Para permitir que los procesos productores y consumidores trabajen concu-

rrentemente, supondremos que disponemos de vectores de memoria interme-

dia, espacios de memoria que los productores llenan con los datos generados

y de donde los consumidores obtienen los datos que hay que tratar.

1) Un productor y un consumidor con un vector de memoria intermedia

ilimitado

En una primera versin vamos a considerar que el tamao del vector de me-

moria intermedia es ilimitado y que tenemos un nico productor y un nico

consumidor. Una vez inicializado el sistema, el primer proceso que tenemos

que poder ejecutar es el productor. Cuando ya se han producido datos, el con-

sumidor puede empezar a tratar la informacin.

En el cdigo que se propone a continuacin se utiliza un nico semforo,

producido, inicializado en 0. Esto quiere decir que no es posible entrar en la

En un sistema es habitual encontrar procesos con relaciones de produc-

tor-consumidor. En general, un proceso productorgenera informacin

que ser consumida (tratada/manipulada) por el proceso consumidor.

Un proceso de teclado...

... se considera un proceso pro-ductor de caracteres que sernconsumidos por el procesopantalla a la hora de hacerel echo(mostrar por pantalla).


31/52


seccin crtica o, dicho de otra forma, si un proceso ejecuta la operacinwait, se

bloquear siempre que ningn otro proceso haya ejecutado la operacinsignal

antes.

a) En este primer caso, el cdigo propuesto por el proceso productores el

siguiente:

b) En este primer caso, el cdigo propuesto por el proceso consumidores el

siguiente:

El semforo producidolleva la cuenta del nmero de datos producidos y to-

dava no consumidos. De hecho, tal y como se ha especificado, el proceso pro-

ductor no necesita pedir permiso para acceder a la variable compartida (vector

memoria intermedia), y lo nico que tiene que hacer es sealar que ha dejado

un elemento nuevo en el vector de memoria intermedia. El productor lo sea-

liza con la operacin signal.

Por otra parte, el proceso consumidor, con la intencin de que el funciona-miento sea correcto, tiene que asegurarse de que hay datos en el vector de me-

moria intermedia antes de intentar acceder a ste. La forma que tiene para

saberlo es ejecutar la operacin wait.

Supongamos que el consumidor no tiene asignado el procesador y, por tanto,

no se ejecuta durante un cierto tiempo. Mientras que el productor va generan-

do datos e introducindolos en el vector de memoria intermedia, para que el

consumidor sepa cuntos datos tiene que procesar una vez que vuelva a ejecu-

tarse cada signaldebe quedar reflejado en la variable producido. En conse-

cuencia, es absolutamente necesario el uso de un semforo n-ario* para tener

constancia del nmero de seales y, por lo tanto, del nmero de datos pen-

dientes de procesar que hay en el vector de memoria intermedia.

Proceso productor

while(cierto) {

/*Producir*/

/*Dejar en el vector de memoria intermedia*/

signal(producido)

/*Otras operaciones*/


Proceso consumidor

while(cierto) {

wait(producido)

/*Leer del vector de memoria intermedia*/

/*Consumir*/



* El hecho de tener msde un dato hace inviable

el uso de un semforo binario.


32/52


El proceso consumidor, cuando ya tiene asignado el procesador, podr entrar

tantas veces en la seccin crtica como datos se renan en el vector de memo-

ria intermedia. Es decir, la operacin waitno lo bloquear hasta que el vector

de memoria intermedia se vace. Esta primera solucin es muy sencilla, y, de

hecho, con ella no aparece ninguna seccin crtica.

El vector de memoria intermedia se puede considerar un vector infinito con

los dos punteros siguientes:

Un puntero denominado entque indica cul es la posicin libre siguiente

del vector de memoria intermedia.

Otro puntero, denominado sal, que indica cul es la primera posicin del vec-

tor de memoria intermedia que tiene datos vlidos pendientes de ser tratados.

En un principio, los dos punteros se inicializan a 0. El productor slo modifica

el puntero ental ejecutar la funcin dejar_en_el_buffer, y el consumidor, por su

parte, modifica el puntero salal ejecutar la funcin leer_del_buffer, de manera

que no se produce ningn tipo de conflicto.

2) Varios productores y varios consumidores con vectores de memoria in-

termedia ilimitados

Si tenemos en cuenta la posibilidad de tener ms de un productor y ms de un

consumidor, las cosas cambiarn un poco y no podremos utilizar el cdigo que seha mostrado antes. Todos los productores, al ejecutar la funcin dejar_en_el_buffer,

modifican una variable compartida: el puntero ent; asimismo, todos los consu-

midores, al ejecutar la funcin leer_del_buffer, modifican una variable compartida:

el puntero sal.

A continuacin proponemos el cdigo necesario para garantizar la ejecucin con-

currente en el caso de tener Nprocesos productores yMprocesos consumidores.

a) En este segundo caso, el cdigo propuesto por los procesos productores

es el siguiente:

Proceso productor

while(cierto) {

/*Producir*/

wait(exclusion)

/*Dejar en el vector de memoria intermedia*/

signal(exclusion)

signal(producido)


}/*Fin while (cierto)*/


33/52


b) En este segundo caso, el cdigo propuesto por los procesos consumido-

reses el siguiente:

El problema que plantea la gestin de tantos procesos se soluciona con unnuevo semforo, denominado exclusione inicializado a 1, para que as el

primer proceso que intente acceder a la seccin crtica tenga la posibilidad de

hacerlo. Como en el caso anterior, un consumidor no intentar entrar en la

zona crtica hasta que algn productor no haya generado datos. En esta solu-

cin tambin sera posible utilizar dos semforos diferentes para asegurar la

exclusin mutua en el acceso de los procesos al vector de memoria intermedia,

uno para los consumidores y otro para los productores. Con dos semforos se

conseguira una mayor concurrencia entre productores y consumidores.

3) Varios productores y varios consumidores con vectores de memoria in-

termedia limitados

En la tercera versin consideramos que tenemos un nmero de productores y

consumidores ilimitado y, adems, que el tamao del vector de memoria in-

termedia es limitado (tiene una capacidad mxima). En tal caso, el vector de

memoria intermedia es un recurso compartido por todos los procesos, y lo de-

finimos como un vector, buffer[0..capadidad 1], de capacidad finita

e igual a capacidad, ms dos punteros, enty sal, inicializados a 0. Los pun-

teros indican cul es la primera posicin libre del vector de memoria interme-

dia (ent) y cul es la primera posicin de este vector que contiene informacin

til (sal). El vector de memoria intermedia se encuentra vaco cuando los

punteros son iguales, es decir, cuando ent = sal. El vector de memoria in-

termedia est lleno cuando ent + 1 mod capacidades igual a saly se trata

de manera circular.

a) En este tercer caso, el cdigo propuesto por los procesos productoreses

el siguiente:el siguiente:

Proceso consumidor

while(cierto) {wait(producido)

wait(exclusion)


signal(exclusion)

/*Consumir*/


}/*Fin while(cierto)*/

Proceso productor

while(cierto) {

El semforo exclusiones binario.El semforo producidoes n-ario.


34/52


b) En este tercer caso, el cdigo propuesto por los procesos consumidores

es el que se sigue:

En la solucin propuesta se han definido cuatro semforos:

c_exclusiony p_exclusion, que son semforos binarios inicializados a 1.

puedeproducir, que es un semforo n-ario y se inicializa a la capacidad

del vector de memoria intermedia, de manera que estamos permitiendo

llenar el vector de memoria intermedia. Si sta se llena, el siguiente produc-

tor que intente introducir algo ms se quedar bloqueado hasta que algn

consumidor consuma datos, deje espacio libre en el vector de memoria in-

termedia y ejecute signal(puedeproducir).

puedeconsumir, que es un semforo n-ario inicializado en 0, ya que en un

principio el vector de memoria intermedia est vaco y no hay nada para

consumir. Los procesos productores cada vez que dejan algo en el vector de

wait(puedoproducir)

/*Producir*/

pfecha = producir

wait(p_exclusion)

/*Dejar en el vector de memoria intermedia*/buffer[ent] = pfecha

ent = (ent + 1) mod capacidad

signal(p_exclusion)

signal(puedeconsumir)


}/*Fin while (cierto)*/

Proceso consumidor

while(cierto) {

wait(puedeconsumir)

wait(c_exclusion)


cfecha = buffer[sal]

sal = (sal + 1) mod capacidad

signal(c_exclusion)

signal(puedeproducir)

/*Consumir*/


}/*Fin while (cierto) */


35/52


memoria intermedia lo identifican consignal(puedeconsumir). El valor

del semforo puedeconsumirser como mximo el valor de capacidad,

es decir, el nmero de seales (signals) en este semforo que se pueden eje-

cutar antes de que el vector de memoria intermedia se llene.


36/52


7. La comunicacin entre procesos. El paso de mensajes

Hemos tenido la posibilidad de comprobar que repartiendo la realizacin deuna actividad entre un conjunto de procesos que se pueden ejecutar de manera

concurrente es posible mejorar considerablemente el rendimiento del sistema.

El hecho de llevar a cabo las actividades conjuntamente plantea la necesidad de

sincronizar y de comunicar los datos, ya sean datos parciales, resultados finales,

etc. A menudo las dos acciones resultan necesarias y, por este motivo, se han de-

sarrollado mecanismos que permiten la sincronizacin y, al mismo tiempo, el

intercambio de informacin.

En general, un mensajees un conjunto de informacin que se puede inter-

cambiar entre un emisor y un receptor. Un mensaje puede contener cualquier

tipo de informacin; su formato es flexible pero, por norma general, incluye

campos para indicar el tipo, la longitud, los identificadores del emisor y del

receptor y un campo de datos. De hecho, toda esta informacin y la que se

pueda aadir se clasifica en los dos grupos que ahora presentamos:

El encabezamiento, con un formato predefinido en un sistema, contiene

la informacin necesaria para que el mensaje pueda llegar a su destino co-

rrectamente. Su longitud suele ser fija.

El cuerpo, constituido por el mensaje propiamente dicho. Suele ser de lon-

gitud variable.

7.1. La implementacin de los mensajes

Un sistema que soporta mensajes, por norma general, ofrece dos tipos de ope-

raciones: enviar_mensaje (send)y recibir_mensaje (receive). La implementacin

especfica de los mensajes en un sistema afecta de manera directa a los parme-

tros que se tienen que pasar a estas funciones. As pues, pasamos a describir con

ms detalles algunas cuestiones que hay que tener en cuenta a la hora de definir

un mecanismo de paso de mensajes, que son:

Los mensajes directos y los indirectos.

La comunicacin sncrona y asncrona.

La longitud de los mensajes.

El paso de mensajeses un mecanismo bastante sencillo e intuitivo quepermite la sincronizacin y la comunicacin entre procesos que se estn

ejecutando en sistemas centralizados o distribuidos.

Muchos sistemas

operativos actuales...

... proporcionan algnmecanismo que permite lacomunicacin de los procesosmediante el paso de mensajes.Por ejemplo, UNIX ofrece unaimplementacin especificade este mecanismo.


37/52


7.1.1. Los mensajes directos y los indirectos

1) Los mensajes directos

Por ejemplo, si tenemos dos procesosA yB, yAdesea enviar un mensaje a

B, se podra ejecutar en ambos procesos el siguiente cdigo:

dondeAy Btienen que ser los identificadores de los procesos dentro del siste-

ma, y la variable mensajecontiene la informacin que se estn intercambian-

do. Este tipo de comunicacin se denomina comunicacin simtrica, ya que

cada emisor tiene que conocer todos los posibles receptores, y a la inversa.

2) Los mensajes indirectos

As, por ejemplo, si el procesoAquiere enviar un mensaje al proceso Bmedian-te un buzn, los procesos podran ejecutar las siguientes instrucciones:

El procesoAdeja el mensaje en el buzn que se le ha designado, buzon1, me-diante la operacin send(buzon1,mensaje), y el proceso B, cuando lo quiere

leer, lo extrae del buzn mediante la operacin receive(buzon1,mensaje).

Si el tipo de mensaje es directo, el proceso emisor tiene que identificarcul es el proceso receptor, y a la inversa, el proceso receptor tiene que

identificar cul es el proceso de quien quiere recibir el mensaje.

Proceso A

... send(B, mensaje)

Proceso B

... receive(A, mensaje)

Cuando el tipo de mensaje es indirecto, el proceso emisor no tiene que

indicar cul es el proceso receptor, y el proceso receptor tampoco tiene

que indicar cul es el proceso emisor. Los mensajes se envan y se reci-

ben mediante ciertas estructuras que ejercen de intermediarias; dichas

estructuras se denominan buzonesa causa de su funcionamiento.

Proceso A

... send(buzon1, mensaje)

Proceso B

... receive(buzon1, mensaje)


38/52


Cuando se dispone de un mecanismo de este tipo tambin son necesarias otras

operaciones para el mantenimiento del buzn, como pueden ser las de crear y

destruir un buzn.

Consideraremos que intentar leer (receive) de un buzn vaco bloquea la ejecu-

cin del proceso, e intentar escribir (send) en un buzn lleno tambin lo hace.

La comunicacin mediante buzones permite la comunicacin de uno a uno,

de uno a muchos, de muchos a uno y de muchos a muchos (seguramente con

ciertas restricciones).

El sistema operativo UNIX ofrece un tipo de comunicacin indirecta, median-

te una clase de buzones denominadospipes. Este mecanismo hace posible la

comunicacin de procesos con parentesco* y permite una buena comunica-

cin entre cualquier nmero de emisores y receptores.

7.1.2. La comunicacin sncrona y asncrona

Las ventajas de la comunicacin sncrona se basan en su fcil implementacin

y en su bajo coste de recursos. Adems, este modo de comunicacin permite

establecer un punto de sincronismo entre el emisor y el receptor: el emisor

puede estar seguro de que el mensaje ha sido recibido. No obstante, esta sin-

cronizacin puede suponer un problema grave en ciertos tipos de servidores.

Mediante la comunicacin asncrona aumenta el grado de concurrencia del

sistema. Y, como inconveniente, hay que mencionar la gestin de los vectores

La comunicacin sncronase basa en el intercambio sncrono de men-

sajes. Dicho intercambio implica que el emisor y el receptor acaben la

transferencia de informacin en el mismo momento, es decir, que es ne-

cesario que se sincronicen. En sistemas sncronos, la operacin sendes

bloqueadora; por tanto, si un emisor quiere enviar un mensaje y el recep-

tor todava no ha efectuado la operacin complementaria, receive, el

emisor queda bloqueado. Por tanto, slo puede haber un nico mensaje

pendiente para cada pareja de emisor/receptor.

La comunicacin asncronano bloquea el proceso, y el sistema opera-

tivo se encarga de guardar el mensaje temporalmente en la memoria

hasta que se lleva a cabo la operacin receive complementaria. En

este tipo de procedimiento, el emisor, tras haber enviado el mensaje,

puede continuar su ejecucin de manera independiente con respecto a

lo que hagan los receptores.

Podis ver las pipesen el subapartado 5.1. delmdulo didctico Los dispositivosde entrada/salida.

* El parentesco indica el grado de

relacin entre los procesos. As,tenemos procesos padre, hijos,

hermanos, nietos, etc.


39/52


de memoria intermedia para almacenar los mensajes pendientes, que es el as-

pecto ms complicado de este mtodo de comunicacin.

7.1.3. La longitud de los mensajes

Por ltimo, no podemos dejar de considerar la longitud de los mensajes, que

puede ser fija o variable. As pues, a la hora de decidir la longitud de los men-

sajes tendremos en cuenta que hay que llegar a un compromiso entre la flexi-

bilidad de los mensajes de longitud variable y la sencillez y la facilidad de

gestin de los mensajes de longitud fija.

7.2. La exclusin mutua mediante mensajes

Un mtodo muy sencillo para implementar la ejecucin concurrente en exclu-

sin mutua es mediante mensajes indirectos. En el ejemplo que se muestra a

continuacin, se crea un buzn que denominamos buzon. Para solicitar acce-

so a la seccin crtica, el proceso lee del buzn con la operacin receivey

entonces:

Si el buzn est vaco, el proceso se queda bloqueado esperando que alguien

le escriba el mensaje.

Si el buzn est lleno, el proceso lee el mensaje, deja el buzn vaco y acce-de a la seccin.

Nos interesa que el primer proceso que solicite acceso a la seccin crtica pueda

pasar. Por esta razn es necesario que el buzn se inicialice introduciendo en

ste un mensaje de cualquier longitud. En el cdigo que se presenta a conti-

nuacin, el buzn desarrolla un papel equivalente al de un semforo binario.

El cdigo que se propone con este proceso es el siguiente:

Asimismo, sera posible implementar semforos n-arios con buzones, con lo

que se permitira que en el buzn pudiese haber hasta nmensajes.

while(cierto) {

receive(buzon, mensaje);

seccin crtica;

send(buzon, mensaje);


Podis ver los semforos en elapartado 4 del presente mdulodidctico.


40/52


8. Los problemas de coordinacin entre procesos(deadlock)

En los sistemas actuales, que contienen un nmero de dispositivos y un n-

mero de procesos considerablemente grande, la posibilidad de la ejecucin

concurrente/paralela de estos procesos y la posibilidad de acceder de manera

concurrente a los dispositivos aumenta el rendimiento del sistema de forma

significativa.

Este maremgnum de procesos y recursos a los que se accede al mismo tiempo

de manera compartida o exclusiva puede generar fcilmente situaciones de

bloqueo (deadlock) que hacen disminuir el rendimiento del sistema.

Es frecuente que los bloqueos aparezcan en sistemas concurrentes como con-

secuencia de la asignacin de recursos del sistema de manera incontrolada, es

decir, sin buscar o establecer ningn protocolo que intente evitar la situacin.

En muchas ocasiones, es el propio programador de los procesos quien crea esta

situacin de manera tanto voluntaria como involuntaria.

Veamos un ejemplo; supongamos que un sistema tiene un dispositivo impre-

sora y un dispositivo disco, a los que hay que acceder en exclusin mutua. Se

crearn dos semforos binarios, discoe impresora, inicializados a 1 para in-

dicar que los recursos estn libres. En el sistema creamos dos procesos que seejecutan de manera concurrente.

a) El cdigo propuesto para el primer proceso, P0, es el siguiente:

Un bloqueo(deadlock) es una situacin en la que un grupo de procesos

permanece bloqueado de manera indefinida, sin ninguna posibilidad

de que contine su ejecucin. En trminos generales, la causa de este

bloqueo indefinido es que cada proceso del grupo ha adquirido un con-

junto de recursos necesarios para operar y est esperando otros recursos

que han sido asignados a otros procesos del grupo. De este modo se crea

una situacin en la que ningn proceso puede continuar su ejecucin.

/*Acciones propias del proceso*/

wait (disco)

wait (impresora)

/*Utilizar el disco y la impresora*/

signal (impresora)

signal (disco)



41/52


b) El cdigo propuesto por el segundo proceso, P1, es el que ahora presen-

tamos:

Podemos observar que la ejecucin secuencial de estos dos procesos es total-

mente correcta y no comporta ningn error. En cambio, a la hora de ejecutarse

de manera concurrente, y en funcin de cmo se entrelazan las operacionesde ambos procesos, se puede generar una situacin de bloqueo indefinido. Por

ejemplo, si se produce la siguiente secuencia:

1) El proceso P0solicita el recurso discoy se le concede, wait(disco).

2) El proceso P1solicita el recurso impresoray se le concede, wait (impre-

sora).

3) El proceso P1solicita el recurso discoy se queda bloqueado, wait (disco),

ya que el disco ha sido asignado. El proceso P0solicita el recurso impresoray

se queda bloqueado, wait (impresora), puesto que este recurso ha sido asig-

nado al proceso P1.

A partir de este momento, el proceso P1se espera a que se libere el recurso

disco, pero ste se ha asignado al proceso P0, que no lo puede liberar porque

se encuentra bloqueado esperando el recurso impresora. ste tampoco ser

liberado, ya que el proceso que lo tiene asignado, el proceso P1, tambin est

bloqueado. En definitiva, se ha creado un bucle de espera que no tiene salida.

Para que se produzca un bloqueo se tienen que dar estas condiciones:

Exclusin mutua: hay que acceder a los recursos en exclusin mutua.

Retencin y espera: cada proceso tiene asignados ciertos recursos y espera

a que se liberen otros.

No expropiacin: los recursos que un proceso tiene asignados slo se libe-

ran a peticin explcita del proceso, el sistema no se los puede quitar.

Espera circular: los procesos bloqueados forman una cadena circular en la

que cada proceso tiene un conjunto de recursos asignados y algunos han

sido solicitados por el siguiente proceso de la cadena.


wait(impresora)wait(disco)

/*Utilizar el disco y la impresora*/

signal(disco)

signal(impresora)



42/52


Si coinciden estas cuatro condiciones, podemos asegurar que se ha producido

un bloqueo.

Se han propuesto varios mecanismos para tratar de solucionar este problema,

que podemos clasificar en tres categoras en funcin de su objetivo:

1) Prevenir el bloqueo. Estas propuestas pretenden evitar el bloqueo orde-

nando de manera lineal los recursos del sistema, con el fin de que los procesos

estn obligados a solicitar los recursos que necesiten en un orden creciente

dentro de la ordenacin especificada.

2) Evitar el bloqueo. Estas propuestas se basan en el hecho de asignar slo los

recursos disponibles que no puedan generar ningn tipo de bloqueo. Esta tc-

nica necesita llevar a cabo un control detallado de qu recursos se han asigna-

do, a qu procesos se han asignado y si estos procesos estn esperando algn

otro recurso.

3) Detectar y recuperar el bloqueo. Las propuestas que utilizan esta tcnica

dejan que aparezcan bloqueos, al asignar con total libertad los recursos en fun-

cin del orden en que los van solicitando los procesos. De vez en cuando, se

comprueba si se ha producido un bloqueo mediante la observacin de si hay

algn ciclo en el grafo de recursos asignados. As, se determina qu procesos

estn bloqueados y, para cerrar el bloqueo, el sistema reinicia algunos de los

procesos que estaban bloqueados.


43/52


Resumen

A lo largo de este mdulo didctico hemos estudiado con detalle el problema dela sincronizacin de diferentes procesos y hemos dado una idea de cmo se solu-

cionan los problemas de comunicacin de procesos y los bloqueos (deadlock).

Hemos comprobado que en la ejecucin concurrente de procesos la sincroniza-

cines necesaria cuando stos acceden a recursos compartidos (principalmente,

dispositivos y variables compartidas). Sin una sincronizacin adecuada, la eje-

cucin concurrente, al entrelazar la ejecucin de varios procesos, puede produ-

cir errores de temporizacin y puede dejar el sistema inconsistente. Las causas

de estas irregularidades dependen del recurso compartido. As, tenemos las si-guientes causas:

En el caso de variables compartidas, la principal causa de este problema es

la existencia de copias temporales por parte de los procesos concurrentes.

En el caso de los dispositivos compartidos, una sincronizacin incorrecta

puede provocar problemas de bloqueo y, en general, una bajada en el ren-

dimiento del sistema.

Para solucionar los problemas que surgen en el momento de sincronizar los

procesos, se han visto las soluciones que ahora exponemos:

a) En primer lugar, se han propuesto algoritmos de softwarey hemos podido

comprobar que su uso resulta complicado.

b) A continuacin se han estudiado con detalle los semforos, un mecanismo

que permite la sincronizacin de manera sencilla. El principal problema que

presentan es que el programador es el responsable de su buen uso.

c) Tambin hemos visto las soluciones de hardware, que pueden ser muy

potentes y, al mismo tiempo, muy peligrosas en manos de programadores

inexpertos.

Y ya por ltimo, hemos visto el mecanismo de paso de mensajesque, adems

de permitir la sincronizacin, tambin hace posible la comunicacin de infor-

macin entre procesos cooperativos; adems, hemos descrito elproblema del

bloqueo de procesos(deadlock).


44/52


45/52


Actividades

1. Por qu interesa que las zonas de exclusin tengan el menor tamao posible? Poned unejemplo en el que se vean claras las posibles ventajas.

2. Es necesario acceder en exclusin mutua a una variable compartida si slo se quiere con-sultar su valor? Por qu?

3. Demostrad que si las operaciones waity signalno se ejecutan de manera automtica sepuede violar la condicin de exclusin mutua.

4. Proponed una implementacin de los semforos n-arios utilizando semforos binarios.

5. Tenemos un proceso que lee caracteres del teclado y los deja en un vector de memoria in-termedia. Los caracteres se leen de uno en uno con la funcin denominada leer_teclado(c),donde ces el carcter retornado. Si no hay ningn carcter, esta funcin se bloquea. Cuandoel proceso ha llenado un vector de memoria intermedia con 80 caracteres, avisa a otro procesopantalla, que procesar los caracteres del vector de memoria intermedia y los sacar por panta-lla. Este segundo proceso utiliza la funcin denominada procesar_caracter(c). El procesoque lee caracteres trabaja con dos vectores de memoria intermedia de 80 caracteres, BUF1y

BUF2. Cuando llena uno, avisa al escritor mientras va llenando otro, y no empieza a llenar denuevo el primero hasta que no ha quedado libre por completo (hasta que el escritor no lo haprocesado del todo).

6. Escribid el cdigo de dos procesos, uno de lector y uno de escritor, para que los datos delos vectores de memoria intermedia (buffers) aparezcan por pantalla correctamente. Para sin-cronizar los procesos utilizad semforos. Definid qu variables globales y cuntos semforosson necesarios, y especificad de qu tipo tienen que ser y cmo se deben inicializar.

7. Suponed que tenemos un sistema en el que los productores generan los datos a rachas: du-rante un tiempo producen una gran cantidad de datos y a continuacin permanecen duranteun periodo casi sin actividad. En la segunda solucin del cdigo de los productores y consu-midores que se ha estudiado en este mdulo se ha utilizado un solo semforo para asegurarla exclusin mutua a la hora de acceder al vector de memoria intermedia. Es posible utilizar

semforos diferentes? Tal y como se ha indicado, en caso de que los productores trabajen arachas, qu ganamos? Implementad el cdigo de las operaciones waity signalutilizandolas llamadas para inhibir y desinhibir interrupciones.

8. Un sistema cuenta con tres impresoras,imp1,imp2eimp3, que son compartidas por to-dos los usuarios del sistema. Escribid el cdigo que tendra que ejecutar un usuario cualquieraque pretendiera enviar un trabajo a la impresora. Dicho cdigo se debe implementar tenien-do en cuenta la secuencia de operaciones que ahora presentamos: se intentar enviar la tarea a la impresora imp1; en caso de que imp1est ocupada, se intentar enviarla a la impresora imp2; si imp2tambin se encuentra ocupada, se intentar enviarla a la impresora imp3.Esta secuencia se repetir hasta que alguna de las impresoras est libre.Definid qu variables globales son necesarias, cuntos semforos se precisan, de qu tipo tie-nen que ser y cmo hay que inicializarlos.

9. Implementad un semforo n-ario mediante el uso de mensajes indirectos con buzones.

10.Reelaborad los diferentes cdigos que se han propuesto para la resolucin del problemade los productores y consumidores utilizando mensajes para la sincronizacin de las opera-ciones. Considerad los mensajes indirectos con buzones.

11. Considerad la comunicacin entre procesos mediante el uso del esquema de los buzones.Estimad buzones infinitos (sendno bloquea nunca).a) Suponed que un proceso quiere esperar un mensaje del buzon-Ay un mensaje del buzon-B(un mensaje de cada buzn). Qu secuencia de sendsy receivestendra que ejecutar?b) Qu secuencia de sendsy receivesse tendra que ejecutar si el propio proceso quiere esperarun mensaje de un buzn o un mensaje del otro, de buzon-Ao de buzon-B?

Ejercicios de autoevaluacin

1. Os proponemos que hagis un generador de nmeros aleatorios. Los nmeros se irn obte-niendo de un vector de memoria intermedia (buffer) circular de tamao maxbuff, donde varios


46/52


flujos irn insertando y extrayendo nmeros siguiendo el esquema del productor/consumidor.El sistema se compone de estos tres tipos de flujos: El flujo productor, que se encarga de crear nmeros y los va introduciendo en un vector

de memoria intermedia con una poltica de asignacin FIFO compartida por todos los flu-jos. Puesto que este vector posee un tamao finito, los flujos productores se bloquearncuando est lleno.

El flujo aleatorizador, que se encarga de consumir los nmeros. Lo hace tomando los 5 n-

meros ms antiguos del vector de memoria intermedia (si no hay 5, se espera a que estn),aplica la funcin int\x11procesa(X1,...,X5), y obtiene otro nmero como resulta-do. Este nmero se introduce otra vez en el vector de memoria intermedia como si esteproceso fuese un productor.

El flujo consumidor, que se encarga de obtener los valores aleatorios y de entregrselos a quiense los pida. Para hacerlo, en el instante en que necesita un nmero, observa el valor de un n-mero cualquiera de los que se encuentran en el vector de memoria intermedia sin extraerlo.

Solicitamos el cdigo esquemtico de generador de nmeros aleatorios poniendo nfasis enlas partes de sincronizacin y exclusin mutua de estos tres tipos de flujos. La solucin debetener en cuenta que podra haber varios flujos de cada tipo.

2. Tenemos un vector de memoria intermedia circular de tamao N que contiene elementosde un cierto tipo y que permite comunicar diferentes procesos entre s. Algunos procesos losproductores escriben elementos mientras que el vector de memoria intermedia no se encuen-tre lleno, y los otros los consumidores leen elementos de este vector de memoria mientras

no est vaco.Queremos introducir el concepto de prioridad entre los productores y los consumidores. Cadaproceso productor y cada proceso consumidor tendrn una prioridad asociada entre 0 (la me-nos prioritaria) y P 1(la ms prioritaria), donde Pes el nmero de procesos que se encuentraen ejecucin. Tambin querremos que un proceso consumidor no acceda al vector de memoriaintermedia mientras que haya algn otro proceso consumidor con ms prioridad que tambinquiera acceder a ste. De manera anloga, un proceso productor no tiene que acceder al vectorde memoria intermedia mientras haya algn otro proceso productor con ms prioridad quetambin quiera acceder a ste.Implementad la solucin de forma que si damos permiso a un proceso para acceder al vectorde memoria intermedia, el resto de los procesos del mismo tipo que deseen acceder tendrque esperar a que ste lo libere, con independencia de la prioridad de los procesos que soli-citen permiso para acceder.Tenis que resolver este problema utilizando tantos semforos como necesitis, as como me-moria compartida entre los procesos (variables compartidas). Disponis de una funcin que

retorna la prioridad del proceso que lo ejecuta y que recibe el nombre de int prioridad(), queretorna un valor entre 0y P 1.

3. Simulad una horchatera donde trabajan dos personas: un horchatero y un camarero. Elprimero se encarga de hacer la horchata y pasrsela al camarero para que la venda. Los clien-tes, que pueden ser muy numerosos, cuando llegan a la horchatera le piden al camarero unnmero variable de horchatas. ste, tras haberlas servido, avisa al cliente para que las tomel mismo. Mientras no hay clientes, el horchatero contina preparando horchatas y el cama-rero espera nuevos clientes.

/*Definiciones e inicializacin de variables compartidas*/#define true 1int n_horchatas = 0 ;semaphore sem1, sem2, sem3, sem4, sem5, sem6 ;

void camarero () {int tmp, i ;while(true) {

sem_wait(&sem2)sem_wait(&sem5)tmp = n_orchatas ;n_orchatas = 0 ;sem-_signal(&sem5) ;for (i = 0;i


47/52


Ayudas: antes de empezar, leed con atencin todas las preguntas; os puede ayudar elhecho de sustituir los nombres de los semforos por otros ms significativos. Las rutinasservir_horchata, ir_a_la_horchatera, cuantas_horchatas, tomar_horchatas ypreparar_horchata no modi-fican ninguna variable ni ningn semforo compartido.a) Con qu valor inicializarais cada uno de los semforos?b) Para qu se supone que sirven los semforos sem5y sem6? Son realmente necesarios es-tos semforos? Por qu?c) Qu informacin se guarda de manera implcita en el contador del semforo sem1?d) Para qu sirve el semforo sem4?

void cliente() {ir_a_la_horchateria();sem_wait(&s

Sistemas Operativos Mod7

Documents

Transcript of Sistemas Operativos Mod7