Problema de Lectores-Escritores | Solución de preferencia de los escritores

Requisitos previos: problema de lectores y escritores | Conjunto 1 (Introducción y solución de preferencia de los lectores) , semáforos en sincronización de procesos

En la sincronización de procesos, existe un problema de sincronización muy clásico llamado problema de lectores y escritores. El problema tiene varios subproblemas o variaciones, todos relacionados con prioridades, uno de los cuales se analiza en la publicación anterior. La segunda variación se conoce con el nombre de problema de lectores-escritores con prioridad de escritor. 

El conjunto de variables utilizadas para resolver el problema son: –

1. Los lectores , que realiza un seguimiento de cuántos lectores hay a la vez.
2.  Mutex,  protege las variables compartidas.
3. Idle , se utiliza para indicar el número de subprocesos (lector o escritor) en la sección crítica. Si no hay subprocesos, entonces debería ser 1, de lo contrario, 0.

int readers = 0                //Keeps the count of readers
idle = Semaphore (1)           // 1 if no threads are present, else 0
mutex = Semaphore (1)          //Mutex protects the shared counter

Para la variable Semáforo,
esperar() significa «esperar hasta que una condición sea verdadera» y
señal()  significa que «señalar que la condición es verdadera»

readSwitch = Lightswitch ()
writeSwitch = Lightswitch ()
noReaders = Semaphore (1)
noWriters = Semaphore (1)

Primero, exploremos el escenario cuando el Lector tiene prioridad sobre el escritor . 

El enunciado del problema:  establece que, una vez que un lector está listo, los lectores pueden leer el archivo. En otras palabras, ningún lector debe esperar si el lector tiene acceso al objeto, mientras que el escritor espera hasta que el lector lo complete.

Solución cuando el lector tiene prioridad sobre el escritor

Solución de escritores:

• Escritor solicita ingreso a la sección crítica
• Si está permitido entonces, no contiene lectores y escribe. De lo contrario, espera en la cola, hasta que wait() es verdadero
• Sale de la sección crítica

Aquí está el código del escritor :

idle.wait()               //Waits till the critical section is empty.
     //Critical Section for the Writer
idle.signal()            //Signals that the critical section is empty.

Aquí, cuando el escritor estaba en la sección crítica, ningún otro hilo (es decir, lector o escritor) estaba presente en la sección crítica. Primero, un lector verifica si la sección crítica está vacía o no. Si está vacío, continúa allí y prohíbe la entrada al escritor .

Solución del lector:

• Requests de lectores para la entrada en la sección crítica.
• si está permitido, entonces no contiene escritores. Dado que contiene la exclusión mutua, cualquier lector posterior se pone en cola en la exclusión mutua . Los lectores posteriores aún pueden ingresar
• El lector sale de la sección crítica.

Aquí está el   código del lector :

readSwitch.lock ( noWriters )            //Locks the writer
    noReaders.wait ()        signaling  // Waits till the  reader exits the critical section
           //critical section for readers
    noReaders.signal ()        //Signals that reader has exited from the Critical section
readSwitch.unlock (noWriters)           // Unlocks the reader.

La declaración del problema:   requiere que, una vez que un escritor esté listo, ese escritor realice su escritura lo antes posible. En otras palabras, si un escritor está esperando para acceder al objeto, ningún lector nuevo puede comenzar a leer.

Solución cuando el escritor tiene prioridad sobre el lector

Solución de los lectores:

• El lector solicita el ingreso a la sección crítica
• Si está permitido, entonces,

1. Contiene noWriters, pero no contiene noReaders . Por lo tanto, si llega un escritor, puede bloquear noReaders , lo que hará que los lectores posteriores se pongan en cola.
2. Una vez que sale el último lector , envía una señal a noWriters, lo que permite que los escritores en la cola continúen.

Aquí está el código del lector  :

noReaders.wait ()
    readSwitch.lock ( noWriters )   // Locks the writers when readers enter the critical section
noReaders.signal ()                    //Signals that reader is in critical section
    //critical section for readers
readSwitch . unlock ( noWriters )   //Once the reader exits the critical section, then the writer is unlocked.

Solución de escritores:

• El escritor solicita el ingreso a la sección crítica.
• Si está permitido, entonces

1. Tiene tanto   noReaders como noWriters. Esto asegura que ningún lector ni escritor estén en la sección crítica.
2. Si un lector está en la sección crítica, contiene noWriters , pero no contiene noReaders. Por lo tanto, si llega un escritor, puede bloquear noReaders, lo que hará que los lectores posteriores se pongan en cola.
3. Además, writeSwitch permite que múltiples escritores se pongan en cola en noWriters, mientras bloquea los noReaders. Por lo tanto, muchos escritores pasan por la sección crítica sin siquiera señalar a los noReaders.

•   Una vez que el último escritor  abandona la sección crítica, el único lector puede ingresar a la sección crítica.

Aquí está el código del escritor :

writeSwitch . lock ( noReaders )            //Locks the reader
    noWriters . wait ()                        // Waits till the writer is complete.
        //critical section for writers
    noWriters . signal ()                    //Signals that writer has exited from the Critical section
writeSwitch . unlock ( noReaders )         // Unlocks the reader.

Pero esta implementación tiene un inconveniente, es decir, los lectores pueden morirse de hambre o sufrir largas demoras. Para evitar el hambre, se utilizan monitores.