Cómo evitar el hambre de escritor en un bloqueo de lectura y escritura en pthreads

Question

Tengo algunas preguntas con respecto a bloqueos de lectura y escritura en POSIX Pthreads en un sistema * nix, digamos Linux por ejemplo.

Deseo saber cuál es el sesgo predeterminado para el bloqueo de lectura y escritura, es decir, ¿prefiere las lecturas por encima de las escrituras o viceversa? Proporciona alguna API para cambiar este comportamiento predeterminado.

¿Posix pthread proporciona alguna API para que podamos cambiar la pthread_rwlock_t para evitar la falta de escritura? Según lo que he leído (corríjanme si me equivoco), la implementación predeterminada está sesgada hacia los hilos del lector y, por lo tanto, los hilos del escritor pueden enfrentar la inanición.

He leído la implementación de ejemplo de rw lock del libro Programming with Posix threads de David Butenhof.

Deseo saber cómo posix pthreads manejan la inanición de hilos de escritor? ¿Hay algún API con el que podamos establecer los atributos del bloqueo de lectura y escritura que evitaría la escritura de inanición (nunca he oído sobre eso)? ¿O el usuario tiene que manejar este problema?

Si crees que la respuesta está definida por la implementación, por favor dame un ejemplo de cómo se hace en Linux, porque eso es lo que estoy buscando.

Tenga en cuenta que solo quiero soluciones para un sistema * nix. No piense que soy grosero, pero publicar un código específico de Windows es inútil para mí.

Gracias a todos por su ayuda y paciencia :)

Answer 1

Esto en efecto, depende de la aplicación - por lo que desde que han preguntado sobre Linux específicamente, mis comentarios se refieren a la aplicación actual NTPL de pthreads, la cual es utilizado en glibc moderno.

Hay dos problemas relacionados, pero separados, aquí. En primer lugar, existe esta situación:

• Hay bloqueos de lectura actualmente en espera y escritores en espera. Un nuevo hilo intenta tomar un bloqueo de lectura.

La acción predeterminada aquí es permitir que el lector proceda, efectivamente "saltando la cola" sobre el escritor. Sin embargo, puede anular esto. Si usa la función pthread_rwlockattr_setkind_np() para establecer el indicador PTHREAD_RWLOCK_PREFER_WRITER_NONRECURSIVE_NP en el attr que pasa al pthread_rwlock_init(), entonces su rwlock bloqueará al lector en la situación anterior.

La segunda situación es la siguiente:

• Los últimos comunicados titular de la cerradura, y hay dos lectores y escritores de espera.

En esta situación, NPTL siempre despertará a un escritor antes que a un lector.

Tomados en conjunto, lo anterior significa que si se utiliza la bandera PTHREAD_RWLOCK_PREFER_WRITER_NONRECURSIVE_NP, sus autores no deben ser muertos de hambre (por supuesto, ahora un flujo continuo de escritores puede matar de hambre a los lectores. C'est la vie). Puede confirmar todo esto consultando las fuentes (todo es muy legible) en pthread_rwlock_rdlock.c y pthread_rwlock_unlock.c.

Tenga en cuenta que también hay una PTHREAD_RWLOCK_PREFER_WRITER_NP, pero parece no tener el efecto deseado - posiblemente un error (no o posiblemente - ver comment by jilles below).