¿Cómo se implementan los bloqueos de lectura/escritura en pthread?

Question

Cómo se implementan especialmente en caso de pthreads. ¿Qué API de sincronización pthread usan bajo el capó? Un poquito de pseudocódigo sería apreciado.

Answer 1

No he hecho ninguna programación pthreads por un tiempo, pero cuando lo hice, nunca utilicé bloqueos POSIX de lectura/escritura. El problema es que la mayoría de las veces un mutex será suficiente: es decir. su sección crítica es pequeña, y la región no es tan crítica para el rendimiento que valga la pena preocuparse por la doble barrera.

En aquellos casos donde el rendimiento es un problema, normalmente usar operaciones atómicas (generalmente disponibles como una extensión de compilador) es una mejor opción (es decir, la barrera adicional es el problema, no el tamaño de la sección crítica).

En el momento en que eliminas todos estos casos, te quedan casos en los que tienes requisitos específicos de rendimiento/equidad/rw-bias que requieren un verdadero rw-lock; y es entonces cuando descubres que todos los parámetros relevantes de rendimiento/equidad de POSIX rw-lock no están definidos y son específicos de la implementación. En este punto, en general es mejor que implemente el suyo para poder garantizar que se cumplan los requisitos adecuados de imparcialidad/rw-bias.

El algoritmo básico es contar cuántos de cada uno se encuentran en la sección crítica, y si todavía no se permite el acceso a un subproceso, desviarlo a una cola adecuada para esperar. La mayor parte de su esfuerzo consistirá en implementar la imparcialidad/parcialidad adecuada entre el servicio de las dos colas.

El siguiente pseudocódigo parecido a C, tipo pthreads, ilustra lo que trato de decir.

struct rwlock { 
    mutex admin; // used to serialize access to other admin fields, NOT the critical section. 
    int count; // threads in critical section +ve for readers, -ve for writers. 
    fifoDequeue dequeue; // acts like a cond_var with fifo behaviour and both append and prepend operations. 
    void *data; // represents the data covered by the critical section. 
} 

void read(struct rwlock *rw, void (*readAction)(void *)) { 
    lock(rw->admin); 
    if (rw->count < 0) { 
    append(rw->dequeue, rw->admin); 
    } 
    while (rw->count < 0) { 
    prepend(rw->dequeue, rw->admin); // Used to avoid starvation. 
    } 
    rw->count++; 
    // Wake the new head of the dequeue, which may be a reader. 
    // If it is a writer it will put itself back on the head of the queue and wait for us to exit. 
    signal(rw->dequeue); 
    unlock(rw->admin); 

    readAction(rw->data); 

    lock(rw->admin); 
    rw->count--; 
    signal(rw->dequeue); // Wake the new head of the dequeue, which is probably a writer. 
    unlock(rw->admin); 
} 

void write(struct rwlock *rw, void *(*writeAction)(void *)) { 
    lock(rw->admin); 
    if (rw->count != 0) { 
    append(rw->dequeue, rw->admin); 
    } 
    while (rw->count != 0) { 
    prepend(rw->dequeue, rw->admin); 
    } 
    rw->count--; 
    // As we only allow one writer in at a time, we don't bother signaling here. 
    unlock(rw->admin); 

    // NOTE: This is the critical section, but it is not covered by the mutex! 
    //  The critical section is rather, covered by the rw-lock itself. 
    rw->data = writeAction(rw->data); 

    lock(rw->admin); 
    rw->count++; 
    signal(rw->dequeue); 
    unlock(rw->admin); 
} 

Algo así como el código anterior es un punto de partida para cualquier implementación de rwlock. Reflexione sobre la naturaleza de su problema y reemplace el dequeue con la lógica apropiada que determina qué clase de hilo se debe activar a continuación. Es común permitir que un número/período limitado de lectores supere a los escritores o viceversa según la aplicación.

Por supuesto, mi preferencia general es evitar rw-locks por completo; en general, mediante el uso de alguna combinación de operaciones atómicas, mutexes, STM, paso de mensajes y estructuras de datos persistentes. Sin embargo, hay momentos en que lo que realmente necesitas es un rw-lock, y cuando lo haces es útil saber cómo funcionan, así que espero que esto te haya ayudado.

EDITAR - En respuesta a la pregunta (muy razonable), ¿por dónde esperar en el pseudo-código:

he asumido que la aplicación quitar de la cola contiene la espera, por lo que en algún lugar dentro de append(dequeue, mutex) o prepend(dequeue, mutex) existe es un bloque de código a lo largo de las líneas de:

while(!readyToLeaveQueue()) { 
    wait(dequeue->cond_var, mutex); 
} 

que era por eso que pasé en la exclusión mutua correspondiente a las operaciones de la cola.

Answer 2

Cada implementación puede ser diferente, pero normalmente tienen que favorecer a los lectores de forma predeterminada debido al requisito de POSIX de que un hilo pueda obtener el bloqueo de lectura en un rwlock varias veces. Si favorecían a los escritores, cada vez que un escritor estaba esperando, el lector se trababa en el segundo intento de bloqueo de lectura a menos que la implementación determinara que el lector ya tiene un bloqueo de lectura, pero la única forma de determinar eso es almacenar una lista de todos los hilos que contienen bloqueos de lectura, lo cual es muy ineficiente en cuanto a requisitos de tiempo y espacio.