Comment prévenir l'auteur de la famine dans une écriture de lecture de verrouillage dans les pthreads

J'ai quelques questions concernant les verrous en lecture /écriture dans POSIX Pthreads sur un *nix système, disent Linux par exemple.

Je souhaite savoir quel est le biais par défaut pour lire verrou d'écriture, j'.e t il préfère lit plus écrit ou vice-versa ? Elle fournit à certaines api pour modifier ce comportement par défaut.

Ne posix pthread fournir certaines api de sorte que nous pourrions changer la pthread_rwlock_t pour empêcher l'auteur de faim ? De ce que j'ai lu(merci de me corriger si je me trompe), l'implémentation par défaut est biaisé en faveur de threads de lecture et donc l'écrivain threads peuvent faire face à la famine.

J'ai lu l'exemple de la mise en œuvre de rw de verrouillage du livre de la Programmation avec les threads Posix par David Butenhof.

Je souhaite savoir comment posix pthreads poignée de famine de l'écrivain threads ? Est-il une api à l'aide de laquelle nous avons pu définir les attributs de la lecture et en écriture verrouillage empêcher d'écrire faim (je n'ai jamais entendu parler) ? Ou l'utilisateur d'avoir à gérer ce problème ?

Si vous pensez que la réponse est la mise en œuvre définies alors s'il vous plaît me donner des exemple de la façon dont c'est fait sous Linux, parce que c'est ce que je suis à la recherche d'.

Veuillez noter que, je veux juste des solutions pour un *nix système. Ne pensez pas que je suis impoli, mais l'affichage des fenêtres de code est inutile pour moi.

Merci à vous tous pour votre aide et votre patience 🙂

  • À l'aide d'un mutex à la place d'un rwlock pour éviter ce problème. Si le conflit est faible, il est également plus rapide dans certaines implémentations telles que celles de la construction d'une rwlock à partir d'un mutex et une variable de condition).
InformationsquelleAutor ghayalcoder | 2010-02-03
  1. 42

    Ce n'est, en effet, dépendent de la mise en œuvre - alors, puisque vous avez demandé à propos de Linux, plus précisément, mes commentaires sont reportez-vous au courant de NPTL mise en œuvre de pthreads, qui est utilisé dans moderne de la glibc.

    Il y a deux liés, mais distincts, les questions ici. Tout d'abord, il y a cette situation:

    • Il y a des verrous en lecture actuellement détenus, et les écrivains d'attente. Un nouveau thread tente de prendre un verrou en lecture.

    L'action par défaut est de permettre au lecteur de procéder de manière à "sauter la file d'attente" au cours de l'écrivain. Vous pouvez, cependant, modifier. Si vous utilisez le pthread_rwlockattr_setkind_np() fonction pour définir le PTHREAD_RWLOCK_PREFER_WRITER_NONRECURSIVE_NP drapeau sur la attr que vous passez à pthread_rwlock_init(), alors votre rwlock va bloquer le lecteur dans la situation ci-dessus.

    La deuxième situation est la suivante:

    • Le dernier titulaire libère le verrou, et il y a à la fois les lecteurs et les écrivains d'attente.

    Dans cette situation, NPTL va toujours se réveiller un écrivain, de préférence à un lecteur.

    Pris ensemble, le ci-dessus signifie que si vous utilisez le PTHREAD_RWLOCK_PREFER_WRITER_NONRECURSIVE_NP drapeau, vos rédacteurs ne devrait pas être affamé (bien sûr, maintenant un flux continu d'écrivains peuvent mourir de faim les lecteurs. C est la vie). Vous pouvez confirmer tout cela en vérifiant les sources (c'est très lisible1) dans pthread_rwlock_rdlock.c et pthread_rwlock_unlock.c.

    Noter qu'il existe aussi un PTHREAD_RWLOCK_PREFER_WRITER_NP, mais il semble pas avoir le bon effet - très probablement d'un bug (ou peut-être pas à voir commentaire par jilles ci-dessous).

    1. ...ou au moins, il était, à l'époque où j'ai écrit cette réponse en 2010. Les dernières versions de NPTL sont considérablement plus complexe et je n'ai pas re-faire l'analyse.

    • merci beaucoup. C'est ce que je cherchais. Encore une chose, est la fonction pthread_rwlockattr_setkind_np() une api POSIX ou seulement spécifique à linux ? Je ne pouvais pas le voir dans le fichier /usr/include/pthread.h fichier d'en-tête sur mon système linux(peut-être, son vieux). Et ce n' "np" signifie ? Merci beaucoup 🙂
    • Il est répertorié comme un UNIX98 extension ici: nptl.bullopensource.org/Tests/Optimization-level-in-nptl.html, mais je crois que c'est une erreur, et c'est en fait une extension GNU (comme le sont toutes les autres fonctions se terminant en _np). Certainement, dans la pratique, il n'est pas disponible ailleurs. Je présume _np est court pour NPTL, qui signifie "Native POSIX Threads la Bibliothèque". Je ne suis pas sûr exactement de la version de la glibc l'a présenté, mais la glibc 2.7 sur ma boîte a elle. Peut-être demander sur la glibc liste de diffusion?
    • Merci beaucoup fac 🙂
    • Hmm, je pense que j'ai présumé de mal, et _np pourrait bien effectivement dire "non portable".
    • Pourquoi dans le monde, n'importe qui ferait leur RW-verrouillage de la mise en œuvre de la faveur des lecteurs sur les écrivains par défaut est au delà de moi...
    • Je pense que la raison en est que PTHREAD_RWLOCK_PREFER_WRITER_NONRECURSIVE_NP causes de blocage lorsqu'un thread serrures pour la lecture de manière récursive et un écrivain est arrivé entre les deux opérations de verrouillage, et ce blocage est considéré comme "pire" que préférant les lecteurs au cours des écrivains, probablement parce que POSIX nécessite récursive des verrous en lecture. Si le blocage est fixe, il semble y avoir peu de raisons pour différents types de rwlock. Par exemple, si il est un écrivain d'attente, FreeBSD permet au lecteur d'entrer dans le forum le thread possède déjà un rwlock en mode de lecture (il ne suit pas tous les propriétaires rwlocks, juste combien il y en a).
    • Intéressant. Où bien que ne POSIX exiger vrai récursive comportement et pas seulement les multiples "propriétaire" de comportement? Tout ce que je peux trouver est "Si le Thread d'Exécution de la Planification d'option n'est pas prise en charge, elle est mise en œuvre-définir si le thread appelant acquiert le verrou quand un écrivain n'a pas la serrure et il y a des écrivains bloqué sur la serrure.", ce qui semble impliquer que l'impasse dans ce cas est valide...
    • Le paragraphe commençant par "Un thread peut détenir simultanément plusieurs verrous en lecture" des demandes de permis récursive des verrous en lecture. Si elles sont autorisées, il serait étrange si elles bloquées dans un assez normal de la situation. D'autre part, récursive des verrous en écriture peut de blocage ou d'échec.
    • Je suis d'accord que ce serait un peu étrange pour eux de blocage, mais je ne suis pas sûr que c'est nécessaire qu'ils pas l'impasse. Je me demande si il est possible de faire un rwlock qui permet à la fois récursive lire verrouillage sans blocage, et préfère les écrivains, délimitée à l'utilisation de la mémoire. Naïvement, il semble impossible.
    • Merci, j'ai mis à jour pour pointer vers git.

    InformationsquelleAutor caf