Pourquoi verrouiller peut devenir un goulot d'étranglement de programme multithread?Pourquoi verrouiller peut devenir un goulot d'étranglement de programme multithread?
Si je veux souvent ma file d'attente pop() et push() par multithread,
qui verrouillent dois-je utiliser?
Le verrou que vous utilisez dépend de votre plate-forme, mais il aura généralement une certaine saveur de mutex. Sur Windows, vous utiliseriez une section critique et dans .NET, vous utiliseriez un moniteur. Je ne suis pas très familier avec les mécanismes de verrouillage sur d'autres plates-formes. Je resterais loin des approches sans verrou. Ils sont très difficiles à programmer correctement et les gains de performance ne sont souvent pas aussi bons que vous pourriez vous y attendre.
Les verrous deviennent un goulot d'étranglement dans votre programme lorsqu'ils sont soumis à de fortes contraintes. C'est-à-dire qu'un très grand nombre de threads tentent tous d'acquérir le verrou en même temps. Cela gaspille beaucoup de cycles CPU lorsque les threads sont bloqués et que le système d'exploitation passe de plus en plus de temps à passer d'un thread à l'autre. Ce genre de problème se manifeste le plus souvent dans le monde des serveurs. Pour les applications de bureau, il est rare que les verrous posent un problème de performance.
"Pourquoi verrouiller peut devenir un goulot d'étranglement de programme multithread?" - Pensez à un turnstile (aussi appelé un déflecteur), qui ne laisse passer qu'une seule personne à la fois, avec une foule de personnes qui attendent de passer à travers.
Pour une file d'attente, utilisez le verrou le plus simple que votre environnement a à offrir.
Les verrous sont chers à la fois parce qu'ils nécessitent des appels de système d'exploitation au milieu de votre algorithme et parce qu'ils sont difficiles à faire correctement lors de la création du processeur.
En tant que programmeur, il est préférable de laisser les serrures au milieu de vos structures de données aux experts et utiliser à la place un bon multithreaded library tels que Intel's TBB
Pour Queues, vous voulez utiliser des instructions atomiques (dur) ou un spinlock (plus facile) si possible car ils sont bon marché par rapport à un mutex. Utilisez un mutex si vous faites beaucoup de travail qui doit être verrouillé, par exemple modifier une structure arborescente complexe
Dans les packages de threads que je connais, vos options pour les mutex sont récursives et non récursives. Vous devriez opter pour non-récursive - tous vos accès seront lock(); queue_op(); unlock(), il n'est donc pas nécessaire de pouvoir acquérir le verrou deux fois.
Pour une file d'attente, il est facile d'écrire une implémentation libre-lock (google loin)
écluses sont les goulots d'étranglement parce qu'ils obligent tous les autres fils qui les rencontrent pour cesser de faire ce qu'ils font et attendre la verrouiller pour ouvrir, perdant ainsi du temps. Une des idées derrière le multithreading est d'utiliser autant de processeurs que possible à tout moment. En forçant les threads à attendre sur les verrous, l'application abandonne essentiellement la puissance de traitement qu'elle aurait pu utiliser.
"Pourquoi verrouiller peut devenir un goulot d'étranglement de programme multithread?" Parce que les threads en attente restent bloqués jusqu'à ce que la mémoire partagée soit déverrouillée.
vous conseille de lire cet article sur « Concurrence d'accès: Ce que chaque Dev doit savoir sur multithread Apps » http://msdn.microsoft.com/en-au/magazine/cc163744.aspx
Votre question est un peu claire. Pouvez-vous répéter, s'il vous plaît? –
Est-ce une question de devoirs? Si oui, merci de marquer comme tel. – derobert