Le verrou d'essorage est-il utile dans une architecture monocœur à processeur unique?

Question

Je suis confus par la fonction de blocage de spin.

Le verrou d'essorage est utilisé pour empêcher le processus de reprogrammer. Cependant, dans une machine avec un seul noyau, est-il utile d'utiliser le verrouillage de rotation pour empêcher le changement de contexte?

Answer 1

Réponse courte: non.

Selon http://uw714doc.sco.com/en/man/html.3synch/Intro.3synch.html

serrures Spin ne doit pas être utilisé sur un système à processeur unique. Dans le meilleur des cas, un verrou tournant sur un système à processeur unique gaspillera des ressources, ce qui ralentira le propriétaire de la serrure; dans le pire des cas, cela bloquera le processeur.

De: http://blogs.microsoft.co.il/blogs/sasha/archive/2008/08/10/practical-concurrency-patterns-spinlock.aspx

Sur les systèmes mono-processeur, spinlocks ne sont pas nécessaires parce que la synchronisation spinlock est nécessaire uniquement sur IRQLs élevé. Sur les IRQL élevés (au-dessus de l'envoi d'IRQL), un changement de contexte ne peut pas avoir lieu, donc au lieu de tourner le thread acquérant, il suffit de demander une interruption sur l'IRQL concerné et de revenir; l'interruption sera masquée jusqu'à ce que le thread de libération abaisse l'IRQL en dessous de l'IRQL demandé.

Pour les systèmes à processeur unique, le noyau ignore la valeur du nombre de tours et le traite comme zéro, ce qui rend essentiellement un verrou tournant non opérationnel.

Oui, les verrouillages par rotation peuvent être utiles et améliorer l'efficacité de certaines opérations.Cependant, en général, vous devriez commencer avec un mutex, et si le profilage montre qu'il s'agit d'un goulot d'étranglement, vous pouvez envisager un spinlock.

Answer 2

Oui et non; selon le système d'exploitation présent, le cas échéant, et ce que vous essayez d'accomplir. Si vous avez le luxe d'un système d'exploitation multi-tâche et multi-threading complet disponible, vous devez choisir vos primitives dans la collection qu'il vous fournit, sinon vous risquez au pire des inefficacités et une synchronisation inopérante. Chaque système d'exploitation a ses idiomes et ses mécanismes préférés, et ne pas suivre ces conventions peut également avoir des coûts. Plus vous obtenez d'un noyau complet (ou plus profondément dans le noyau et les pilotes de périphériques que vous obtenez), vous trouverez que les meilleurs idiomes impliquent des primitives de synchronisation de niveau inférieur.

Même une seule unité centrale a des gestionnaires d'interruption qui peuvent exécuter (en principe) entre n'importe quelle paire d'instructions, ou même pendant certaines instructions à plusieurs cycles dans certaines architectures. Il s'agit effectivement d'une sorte de concurrence, même si elle est plus faible qu'un second noyau. Les primitives de synchronisation sont donc nécessaires lors de la communication entre le ou les threads de premier plan et les gestionnaires d'interruption en arrière-plan. Dans un seul noyau, la synchronisation entre les threads de premier plan doit impliquer un changement de contexte, bien sûr. Attente d'une condition définie dans un gestionnaire d'interruptions ou dans une condition définie dans un registre matériel sont les deux cas où un seul thread de premier plan dans le noyau unique pourrait avoir le meilleur choix que de tourner sur le drapeau ou le registre.

Modifier: J'ai essayé de clarifier cette réponse pour préciser que je parle de la synchronisation en général plus que la mise en œuvre d'un spinlock spécifique de l'OS. La question n'est pas spécifique sur le système d'exploitation (le cas échéant) et n'est pas non plus étiquetée pour un système d'exploitation spécifique.

Answer 3

Votre observation est bonne: sur un système monoprocesseur, il n'y a pas de raison de tourner pour attendre une ressource, car vous pourrez aussi bien changer de threads plus tôt que plus tard. Mutex et sémaphores font exactement cela.

Sur un système multiprocesseur, un thread sur un autre processeur peut libérer le verrou sans vous basculer vers le contexte. Spinlocks peut être utile, alors, si vous ne vous attendez pas à attendre longtemps, car il peut être plus rapide juste pour traîner jusqu'à ce que l'autre thread déverrouille la chose. Si vous allez dormir sur un mutex, vous êtes essentiellement assuré d'un temps mort important avant que vous ne soyez reporté. En revanche, dans le code noyau, la situation change: les gestionnaires d'interruption doivent accéder aux ressources partagées avec le reste du noyau, mais ils ne peuvent pas dormir. Les mutexs mettent le noyau en veille, donc vous ne pouvez pas les utiliser, mais les spinlocks ne sont pas utiles car rien n'interrompra un gestionnaire d'interruption sur un uniprocesseur (enfin, peut-être une autre interruption, mais c'est effrayant).

Dans un noyau, puis, spinlocks dans un gestionnaire d'interruption compiler à un no-op. Ils sont complètement élidés, comme vous pourriez le penser. En même temps, pour empêcher les courses, les verrouillages dans le reste du noyau désactivent les interruptions juste avant qu'elles ne tournent réellement sur quelque chose (car les tâches du noyau peuvent être planifiées). Ces codes n'ont besoin que de verrous (par opposition aux mutex) s'ils partagent du code avec un gestionnaire d'interruption.

En général, vous avez raison: spinlocks vraiment ne font pas beaucoup de sens sur un monoprocesseur si vous avez mutex, parce que les mutex perdre moins de temps.

Answer 4

No.

Pour une réponse beaucoup plus détaillée, voir "How Do Locks Lock?" ainsi que les commentaires.