Buenas tardes,
Realizando el laboratorio, noté una semejanza entre el problema del laboratorio y el problema de lectores - escritores. Revisando el código de lectores - escritores me surgió la siguiente duda, ¿cómo el código de la diapositiva 13 garantiza la prioridad cuando llega un escritor, y hay lectores leyendo, por sobre los próximos lectores que lleguen?
Quedo atento a su respuesta.
Gracias.
Me sumo a la consulta.
Más específicamente, por plantear un ejemplo, suponiendo el caso en que llega primero un lector, luego un escritor y luego dos lectores más:
El primer lector que llegó toma el "try", y el resto se van a quedar trancado en sus respectivos "try". Ahora cuando éste ejecuta el V(try) la idea para que se cumpla la consigna de prioridad es que se despierte al escritor y no deje entrar a los otros también bloqueados, pero semáforos despierta aleatoriamente, entonces no podes controlar eso.
Se considera igual que está correcta la implementación de prioridad?
Gracias.
En general para dar prioridad tenés que esperar a que el proceso con prioridad altere de alguna forma el estado del sistema para avisar que está esperando. El estar esperando en un semáforo no cambia el estado global del sistema porque no hay forma de saber que está ahí con las herramientas que vemos en el curso. Si tuvieras una API de semáforos que te permitiera saber cuantos procesos están esperando por adquirir un semáforo podrías hacerlo mejor. De hecho esto si lo tenés en ADA con el count de los entries por lo que en ese caso se espera que tengas esto en cuenta y evites esta situación.
Por último, el problema no es que los semáforos no sean FIFO porque con monitores (o mailbox) te puede pasar lo mismo si el escritor debe entrar al monitor para levantar una bandera indicando que llegó y hay 400 lectores encolados en el monitor tratando de entrar antes que él.
Es con el semáforo try. Se considera que el escritor llegó cuando lo toma y a partir de ese momento no pueden entrar más lectores.