Quelle est la différence entre spinlock et polling?

Est-ce que spinlock et polling sont la même chose?

Wikipédia:

un spinlock est un verrou qui oblige un thread à l'acquérir à attendre simplement dans une boucle ("spin") tout en vérifiant à plusieurs reprises si le verrou est disponible

Cela ressemble beaucoup à:

while(!ready);

On m'avait appris à éviter les scrutins chaque fois que c'était possible, car cela était complètement sous-optimal. Alors, est-ce que spinlock est un nom de fantaisie pour le mauvais vieux scrutin? En quoi un spinlock est-il différent du polling?

Une interrogation consiste à vérifier à plusieurs reprises si une ressource ( tout type de ressource) est prête.

Un spinlock se produit lorsque la ressource que vous interrogez est un verrou.

Notez que l'interrogation n'est pas mauvaise. En particulier, l'interrogation est efficace lorsque des données sont généralement prêtes lorsque vous interrogez. La scrutation n'est inefficace que si vous le faites sans récupérer aucune donnée en retour.

D'autre part, les interruptions sont inefficaces s'il y a tellement de données que vous êtes constamment interrompu. Ils sont efficaces si les données arrivent assez rarement pour que vous puissiez effectuer un travail utile avant d'être interrompu.

Je peux vous donner un exemple concret de ma propre expérience: il y a 15 ans, mon programme de messagerie électronique était configuré pour m'interrompre chaque fois qu'un nouveau courrier électronique arrivait. Ce qui se produisait une ou deux fois par semaine. Vérifier constamment ma boîte de réception aurait été une perte de temps colossale.

De nos jours, toutes les notifications sont désactivées. Je sais que chaque fois que je regarde dans ma boîte de réception, il y aura de nouveaux courriels. Le vote est beaucoup plus efficace maintenant.

Les verrous sont efficaces lorsque a) la probabilité que le verrou soit utilisé est faible et b) si le verrou est utilisé, il ne sera maintenu que pendant une courte période. En d'autres termes: il est efficace pour la plupart des verrous à grain fin non contrôlés, mais inefficace pour les verrous à grain grossier très dispendieux.

(Et bien sûr, les spinlocks ne fonctionnent que lorsqu'il y a un vrai parallélisme, sinon l'autre thread n'aura aucune chance de libérer le verrou. Je suppose que c'est assez évident, mais je voulais quand même le préciser.)

Un spinlock est un type de verrou, plus précisément obtenu par interrogation.

L’interrogation est une méthode de vérification de l’état de quelque chose (en demandant l’état, par opposition à attendre d’être informé de l’état).

Toutes les interrogations ne sont pas des verrouillages, par exemple, interroger l'état des touches du clavier.

De plus, les sondages ne sont pas mauvais en soi. De très courtes périodes d'interrogation peuvent éviter des décalages de contexte coûteux liés à l'utilisation d'interruptions, sans oublier que l'interrogation peut parfois être plus simple à mettre en œuvre et donc plus facile à gérer, en particulier aux niveaux les plus bas. Comme d'habitude, les absolus sont une chose terrible, et vous devriez utiliser la méthode qui donne le compromis performance / complexité approprié pour vos besoins tels que vous les avez mesurés , plutôt que d'utiliser aveuglément ou de rejeter des options.

Le spinlock est différent de l'interrogation, car il ne se produit que pendant une très courte période, de l'ordre de quelques millisecondes ou moins. Le vote peut durer indéfiniment.

En programmation parallèle, un bref épisode de rotation est souvent préférable au blocage, car il évite les coûts liés au changement de contexte et aux transitions du noyau.

Lectures complémentaires
SpinLock et SpinWait en C #
Spinlocks et verrous en lecture-écriture en C

La différence est qu’un spinlock n’est (espérons-le) utilisé que dans les situations où il est approprié, et dans ces situations, il est très efficace.

Vous utilisez un verrou tournant si vous prévoyez qu'une ressource ne sera verrouillée que pendant un très court instant, par exemple si un verrou est utilisé uniquement pour mettre à jour une variable. Le spinlock interroge le verrou à la vitesse maximale, mais dans l’espoir moins de quelques microsecondes. Un mutex normal nécessiterait un appel sur le système d'exploitation. SI le verrou n'est maintenu que pendant un temps très court, le spinlock ne consomme que très peu de temps CPU, alors que l'appel du système d'exploitation prend plus de temps. Mais si cette attente est fausse, le spinlock est très inefficace - il utilisera 100% de temps de calcul sur un processeur, tandis que le mutex normal ne prend que le temps nécessaire pour entrer dans le système d’exploitation et y revenir.

Parfois, les deux sont combinés; vous exécutez le verrouillage du spin pendant une courte période et passez à une stratégie différente si le spinlock ne fonctionne pas.

Les sondages excessifs ne doivent pas être utilisés car ils gaspillent des ressources système. Il s'ensuit que le vote est correct s'il ne gaspille pas de ressources système .

Par exemple, une interrogation excessive entraînera une charge du processeur de 100% dans les cas où le travail réel n'entraînerait qu'une charge de 2%.

Le sondage peut être utilisé pour autre chose que while(!ready). Par exemple, cela signifie vérifier régulièrement si l'utilisateur a appuyé sur une touche. Une implémentation saine vérifie au plus une fois toutes les 15 millisecondes. Un contrôle tous les 20 millions de cycles environ. Ce type de sondage est excellent, car il ne gaspille pas de ressources système.

Un SpinLock n'est pas un cas particulier. Si nous avons un SpinLock et qu'un thread entre dans le verrou, et qu'un autre doit attendre, SpinLock est le mauvais choix si et seulement si le thread en attente gaspille des ressources système. Le thread en attente gaspille les ressources du système si et seulement si il doit attendre un laps de temps important avant de pouvoir obtenir le verrou.

Par conséquent, utiliser un SpinLock pour protéger tout ce qui nécessite quelques milliers de cycles d'horloge ou plus avant qu'il ne se débloque à nouveau (par exemple, compiler et exécuter un morceau de javascript à la volée) est mauvais, exactement pour la raison que vous avez indiquée. Mais utiliser un SpinLock pour protéger quelque chose qui se termine rapidement, comme accéder à une carte de hachage correctement implémentée est acceptable, car le thread en attente ne tourne que 2 ou 3 fois et ne gaspille donc pas de ressources système.