Cómo prevenir la inanición del escritor en un bloqueo de lectura y escritura en pthreads
Tengo algunas preguntas sobre bloqueos de lectura-escritura en Pthreads POSIX 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 lecturas sobre escrituras o viceversa ? Proporciona alguna api para cambiar este comportamiento predeterminado.
¿posix pthread proporciona alguna api para que podamos cambiar el pthread_rwlock_t para evitar la inanición de writer ? De lo que he leído (por favor corríjame si me equivoco), el valor predeterminado la implementación está sesgada hacia los hilos de lector y, por lo tanto, los hilos de escritor pueden enfrentar la inanición.
He leído el ejemplo de implementación de rw lock del libro Programming with Posix threads de David Butenhof.
Deseo saber cómo posix pthreads manejar la inanición de hilos de escritor ? ¿Hay alguna api con la que podamos establecer los atributos del bloqueo de lectura y escritura que evitaría la inanición de escritura (nunca he oído hablar de 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 pienses que soy grosero, pero publicar algún código específico de Windows es inútil para mí.
Gracias a todos por su ayuda y paciencia :)
1 answers
Esto de hecho depende de la implementación, así que ya que ha preguntado sobre Linux específicamente, mis comentarios se refieren a la implementación actual de NPTL de pthreads, que se usa en glibc moderno.
Aquí hay dos cuestiones relacionadas, pero separadas. En primer lugar, existe esta situación:
- Hay bloqueos de lectura actualmente retenidos, y escritores esperando. 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 la bandera PTHREAD_RWLOCK_PREFER_WRITER_NONRECURSIVE_NP en el attr que pasa a pthread_rwlock_init(), entonces su rwlock bloqueará el lector en la situación anterior.
La segunda situación es:
- El último soporte libera el bloqueo, y hay lectores y escritores esperando.
En esta situación, NPTL siempre despertará a un escritor en lugar de a un lector.
Tomados en conjunto, lo anterior significa que si usas la bandera PTHREAD_RWLOCK_PREFER_WRITER_NONRECURSIVE_NP, tus escritores no deberían morir 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 comprobando las fuentes (todo es muy legible1) en pthread_rwlock_rdlock.c y pthread_rwlock_unlock.c .
Tenga en cuenta que también hay un PTHREAD_RWLOCK_PREFER_WRITER_NP, pero parece no para tener el efecto correcto - muy posiblemente un error ( o posiblemente no - ver comentario de jilles a continuación).
1. ...o al menos lo era, cuando escribí esta respuesta en 2010. Las últimas versiones de NPTL son considerablemente más complejas y no he vuelto a hacer el análisis.
Warning: date(): Invalid date.timezone value 'Europe/Kyiv', we selected the timezone 'UTC' for now. in /var/www/agent_stack/data/www/ajaxhispano.com/template/agent.layouts/content.php on line 61
2018-06-06 01:07:34