Si je défini 3 threads pour attendre que le mutex soit libéré, formez-vous une file d'attente sur la base de la commande qu'ils la demandait ou constitue-t-elle un comportement indéfini (c'est-à-dire que nous ne savons pas lequel le ramassera d'abord) ?
5 Réponses :
L'ordre de réveil est indéfini, voir
Un seul SetEvent () déclencher plusieurs serviforSingleObject ()
élaborer et citer des sources fiables
Donc, si j'ai une boucle qui verrouille un mutex, fait quelques trucs, puis la sortie ... La prochaine itération pouvait ramasser le verrou avant qu'un autre fil ait eu le temps de le verrouiller ... Si tel est le cas, qu'est-ce que c'est considéré. Un temps de sommeil raisonnable pour permettre à un autre fil de verrouiller le mutex?
S'il y a tellement de contentions sur le mutex que cela montre, les threads contenaient-ils non efficacement sérialisés? S'ils sont sérialisés, pourquoi ne pas utiliser qu'un seul fil et aucun verrouillage?
Oui, un seul thread sera réveiller et verrouiller le mutex. Mais l'ordre est indéfini.
Il semble y avoir des opinions très mixtes à ce sujet et aucune information claire nulle part. Dans ce fil: http: //us.generation-nt .com / réponse / sont-les-événements-Fair-hel-38447612.html Certaines personnes semblent suggérer que l'équité des événements est mise en œuvre à l'aide d'une simple file d'attente FIFO qui ignore les priorités, tandis que d'autres disent que l'équité ne devrait pas être supposée .
En bout de ligne, je pense que vous feriez mieux de ne pas baser votre logique sur l'équité ou d'envelopper un événement avec votre propre implémentation qui garantit l'équité.
Il est explicitement documenté dans Article SDK :
Si plusieurs threads attendent sur un mutex, un fil d'attente est sélectionné. Ne présumez pas un ordre premier, premier sorti (FIFO). Des événements externes tels que les APC en mode Kernel peuvent changer l'ordre d'attente.
Ces types d'événements sont entièrement hors de votre contrôle. Donc, un comportement non défini "est un moyen approprié de la décrire.
En pratique (bien que certainement pas garanti), c'est FIFO.
L'objet mutex est surtout juste. L'affaire APC peut survenir, mais ce n'est pas ce courant. Surtout si le fil ne fait pas d'E / S ou effectue des E / S en utilisant des ports d'achèvement ou de manière synchrone.
La plupart des serrures de mode utilisateur Windows (SRWLock, critique) sont injustes si vous pouvez les acquérir sans blocage mais juste si vous devez bloquer dans le noyau. La raison pour laquelle il est fait de cette façon est d'éviter les convois de verrouillage. Au moment où une serrure équitable devient affirmée, chaque acquéreur doit passer par le planificateur et le chemin d'interrupteur de contexte avant d'obtenir la serrure. Personne ne peut "sauter à venir" et prendre la serrure parce qu'elles arrivent à courir. Ainsi, la serrure d'acquérir du temps pour le dernier fil dans la file d'attente augmente par le temps d'interrupteur de planification et de contexte pour chaque thread antérieur dans la file d'attente. Le système ne récupère pas de cet état jusqu'à ce que la charge externe est principalement supprimée car il s'agit d'une condition stable.
Pour la performance, je vous recommanderais d'utiliser l'un des verrouillages en mode utilisateur susmentionné, car ils sont beaucoup plus rapides qu'un noyau mutex, s'ils entrent dans votre scénario.
Bonjour, et bienvenue au débordement de la pile! Merci d'avoir répondu à cette question avec une réponse utile et faisant autorité. Cependant, à l'avenir, Veuillez ne pas "signer" vos messages. qui ajoute simplement un "bruit" supplémentaire et est une pratique que nous décourager ici. Cela dit, il n'y a rien de mal à informer les personnes que vous êtes membre de l'équipe Windows Kernel et, en fait, nous encourageons la divulgation de ce type d'informations. Vous devez utiliser le champ "À propos" (également appelé Big Grey Box) dans votre page de profil personnel pour partager des informations comme celle-ci.