Reporte de lectura II

Benito Vicente Franco López

Noviembre 29, 2020

Abstract
En la lectura de Dijkstra se ataca los principales problemas del computo concurrente y la comunicaión
entre procesos,más especificamente como comunicarlos a traves de un buffer y evitar que los procesos
interfieran entre si, se atacan varias soluciónes como soluciónes por semáforos o candados y se nos hace
concientes de la dificultad de este problema

1 Comunicación a traves de variables de estado

En el capitulo anterior habiamos visto la solución del semáforo general,las reglas de comportamiento para
el consumidor eran simples si hay algo en el biuffer consumelo, cuando tenemos un grupo de procesos que
interactuan entre si, es necesario no solo que las partes funcionen bien, si no que entre ellas puedan interactuar
de manera adecuado, en esta parte el autor nos invita a construir un tipo de programación paralela. Se nos
hace advertencia que en las siguientes partes la interacción puede implicar decisiones relacionadas con más
de un proceso y no siempre es obvio cuál de los procesos deberı́a hacerlo, se impondraalguna regla que nos
indique al cual proceso corresponde en ese caso

1.1 Un ejemplo de regla de prioridad

En esta sección se nos presenta un problema de consumidor productor más general donde los productores
pueden dar porciones de distintos tamaños, los cuales estan en unidades de porciones, esta vez podria pasar
que aunque el buffer no este lleno la porcion que el productor trae para poner en el buffer sea insuficiente
por lo que el porductor no podra poner su porción, si dos productores quieren accerder al mismo tiempo al
buffer le daremos prioridad a aquel que tenga la porción más grande,en caso de que los dos tengan el mismo
tamañao de porción no nos importara quien acceda primero al buffer, se hace la observación de que si un
procutor no puede acceder al buffer los otros tampoco, por que su porción es más grande o bien porque su
porción es más pequeña y tiene menor prioridad de acceso, para la solución de este problema se introduce
la variable desire = 0 que son las unidades que faltaron para que el productor pueda poner su producto y
otra variable interna llamada producersemaphore, se introduce la variable buf man, encargada de cambiar el
estado de las variables anteriores y el acceso al buffer y finalmente tentativamente se introduce una variable
de estado entera ” number of free buffer units” que nos dice cuantas unidades de espacio hay en el buffer. por
otro lado el semáforo ” number of queuing portions”contará las porciones real y completamente llenas y aún
inadvertidas para los consumidores”, number of free buffer units”contará las unidades completamente libres y
no asignadas en el búfer se introduce el entero ” buffer blocking”, cuyo valor es igual al número de cantidades
” desire” que son positivos sirve como advertencia a los consumidores de que se necesita un aviso adicional, en
la siguiente parte el autor nos muestra un codigo de la solución del problema, los productores seguiran agre-
gando porciones al buffer cuando buf f er −blocking = 0 y number −of −f ree−buf f er −unitsportion−size
de manera directa en caso de que alguna de estas dos condiciones no se cumpla el productor se ira a dormir
y encargara que alguno de los consumidores lo despierte a su debido tiempo, si ”buffer blocking¿ 0 ” los
consumidores se encargaran de ver a que productor despertar pues saben que al menos uno de ellos se ha
dormido, el autor nos muestra que esta acción cumple 3 objetivos:
el ”número de unidades tampón libres” se reduce en el número de unidades deseadas. Por lo tanto, garanti-
zamos que no se puede otorgar el mismo espacio libre en el búfer a una yegua que a un productor. Además,
esta disminución está de acuerdo con el comportamiento del productor.

1
 El ”deseo” del productor en cuestión se pone a cero; esto es correcto, ya que su solicitud ha sido concedida;
el bloqueo del búfer se reduce en 1 en consecuencia.
Una operación en V en el semáforo del productor en cuestión despierta al productor dormido, una vez
finalizado este proceso el consumidor vuelve a checar si hay productores dormidos el proceso solo termina
cuando ”buffer-blocking=0” ya no hay productores durmientes, o no hay suficente espacio para los produc-
tores

1.2 Un ejemplo de conversaciones

En este ejemplo se ataca otro problema donde uno de los procesos no es una maquina sino una persona el
”operador”, el se comunicara con los procesos a traves de un canal semiduplex, se le llama asi porque solo
envia información en una dirección, se nos dice que cada proceso va haciendo le preguntas al poperador
para decidir que hacer el cual otorga dos posibles respuestas A1,A2, no se reciben 2 preguntas a la vez,
por lo que se implementa algun tipo de sincronización ademas de un identificador de respuesta que diga a
que proceso esta dirigido, por otro lado se agrega una respuesta A3 que le permite al operador posponer su
respuesta hasta más adelante,el autor comenta que en este problema se le da prioridad a los mensajes que
son proporcionados por el operador de manera que el canal no sea arrebatado por uno de los procesos el
autor resuelve el problema como sigue:
Se introduci un proceso que sea el ”interprete de los mensajes” un arreglo con las variables de estado de
cada procesos, semáforos que permitan sincronizar los proces y la variable mutex que atienda la exclusión
mutua durante la identificación o modificación de variables comunes, para completar la soluciones debemos
definir bien, cuales van a ser nuestros estados y que estructura dar a los N + 1 procesos, obsefve que nuestras
variables de estado deben tener sentido si mutex = 0, especificar el estado total del sistema pero a la vez
referirse a un proceso en particular, cada proceso debe verificar estas variables de estado antes de continuar.
El autor crea la variable procvar que indica el estado del proceso y le da un número dependiendo de si el
proceso esta esperando el mensaje del operador, este ha sido retrasado,respondido o no hay disponibilidad
del canal de comunicación, por otro lado se crea la variable comvar que nos dice como utilizar la función
de comunicación. Despues de esto se nos muestra la implementación de una solución en Algol 60, y se nos
muestra como mejorarla en la siguiente sección. Para continuar con la lectura se nos muestra la correctitud
del programa, observando cuales son los posibles estados en los cuales se puede estar a lo largo de este y
como es que el programa soluciona estos problemas de una manera adecuado dependiendo de los valores de
comvar además de que se separa el espacio de estado en regiones y se nos dice que hacer en cada situación

2 El problema del abrazo mortal

En esta sección el autor nos explica el problema del abrazo mortal y como este es provocado cuando en un
conjunto de procesos, todos los procesos estan esperando una acción que solo puede ser realizada por algun
otro de los procesos,podemos asociar este problema con el problema de los filosofos el cual vimos en clase,
donde los tenedores serian los recursos compartidos y cada filosofo seria un proceso, ela utor dice que este
es el mismo principio básico de que dos hombres no pueden usar una puerta giratoria al mismo tiempo,aqui
como proceso entendemos a un programa que realiza la computadora el cual termina siempre que se le
asignen los recursos necesarios que solicita el proceso, la demanda de espacio de almacenamiento puede ser
una función del tiempo acotada superiormente, se admite correr programas al mismo tiempo siempre que la
suma de sus demandas máximas no exceda la capacidad total de almacenamiento, para este problema cada
proceso solicita recursos a priori, y puede solicitar más durante la ejecución por lo que se reserva un espacio
de memoria para esta solicitud, sin embargo podria pasar que este espacio fuera insuficiente y necesitaramos
eliminar el proceso anterior para continuar con el primero es aqui donde el autor hace referencia al concepto
de abrazo mortal, la pregunta es como solucionar este problema.

2.1 Algoritmo del banquero

En esta sección se nos cuenta la historia de un banquera que presta florines sujeto a la condición de que
cada prestamo tiene un tope máximo de los florines que puede pedir, el prestamo se completa en un periodo
finito y el cliente puede ir pidiendo florines siempre y cuando no exceda el monto máximo, si alguien solicita

2
un florin el banquero puede tardar en darselo,las preguntas a solucionar esta vez son: ¿bajo qué condiciones
puede el banquero firmar el contrato con un nuevo cliente?
¿bajo qué condiciones puede el banquero pagar un (próximo) florı́n a un cliente que lo solicita sin correr el
peligro del Abrazo Mortal?
Para la solución se crean las variables claim,loan,need,cash, cada vez que una persona solicita un florin, el
banquero ve que pasaria si se lo presta, es decir si cash es suficiente para que las transacciones de todos los
clientes puedan termianr en caso contrario le dice que espere,para el algoritmo en vez de verificar todos los
casos, el autor solo verifica aquellos en los que partiendo de una situación segura se investiga que pasaria si el
banquero hubiese dado un florin, el resultado de esta verificacion se guarda en la variable f inish − doubtf ull

2.2 Se aplica el algoritmo del banquero

En esta parte se modifica el problema y esta vez los florines son procesos en si mismos, a cada florin y cada
cliente se les implementa una variable de estado, florvar y cusvar, donde 1 significa que el cliente quiere
pedir prestado o que el florin esta disponible.En términos generales, un préstamo exitoso solo puede tener
lugar cuando se cumplen dos condiciones: f lorin debe solicitarse y f lorin debe estar disponible.El autor
nos hace la observación de que podria pasar que un cliente dejara de usar el florin pero tarde en devolverlo
al banquero por lo que el banquero no lo podria usar asi la tracción solo termina si el florin es devuelto al
banquero en total efectivo, se hace un procedimiento llamado ”try to give to” el cual nos indica si se ha
concedido una devolución retrasada de un florin el autor nos da una implementación en ALGOL 60 y nos
dice que un prestamo es exitoso si y solo si se cumplen dos condiciones: f lorin debe solicitarse y f lorin
debe estar disponible.

3 Conclusiones
A traves de la lectura pude observar que el problema de concurrencia no es nada sencilla y que por muchos
años fue un problema que no tenia una solucion realmente convincente, pues todas las soluciones que se
daban tenian alguna falla tales como que los dos programas se bloquearan asi mismos, o que si alguno de
los dos fallaba,esto generaba una reacción en cadena que hacia que ambos fallaran, o podia pasar que ambos
trataran de acceder al mismo tiempo a una variable y la modicaran de una manera indeseada o no como
se esperaba,en esta ultima parte en particular me pude dar cuenta que la mayor parte de problemas de
concurrencia se dan por el acceso simultaneo a recursos que son compartidos, por otro lado el hecho de que
varios procesos se puedan comunicar a traves de un buffer y que el tamaño de la información a insertar pueda
ser variable hace que el problema se torne mucho más complejo y tengamos que ingeniarnola a partir de
nuevas variables que nos inidiquen, el estado de almacenamiento de buffer por unidad de almacenamiento, si
es posible o no acceder y la prioridad que le debemos dar al proceso a partir del tamaño de la información,
es interesante conocer el problema del abrazo mortal, y darse cuenta como muchas veces el acceso a una
cantidad finita de recursos disponibles por muchos programas, provoca que el sistema se bloque, me gusto
verlo con la metafora del banquera y como este tiene que ir deciendo si prestar o no prestar el recurso en
ese momento para evitar un abrazo morta, además de que en general los florines podrian ser programas en
si mismos y debiamos plantearnos el estado de cada florin.