J'essaie d'optimiser un code multi-threads. Je sais que la façon dont je devrais me concentrer est de rendre la section critique plus petite, mais je rencontre une structure de code et je ne suis pas sûr de ce qui est le meilleur moyen d'améliorer la performance.
La première question est comme ceci: P>
func1(){
mutexA.lock();
critical Section for varibale A;
mutexB.lock();
critical Section for varibale B;
mutexB.unlock();
critical Section for varibale A;
mutexA.unlock();
}
func2(){
if (some condition){
mutexB.lock();
critical Section for varibale B;
mutexB.unlock();
}
}
3 Réponses :
Tout d'abord, gardez-le simple, mais correct. Puis profil. Ensuite, seulement si nécessaire, s'améliore.
Malheureusement, je ne peux pas fournir une réponse plus concrète ici parce que: ici, il est parfait. Si vos "rares lignes qui ne créeront pas de conflit" sont rapides - ne vous embêtez pas. En ce qui concerne votre dernier exemple sur l'utilisation d'un mutex séparé pour chaque variable: généralement cela n'a pas de sens aussi. Si vous modifiez généralement un tas de variables, protégez-les par le même mutex. Démarrer depuis une version plus simple.
Merci pour la suggestion. J'ai édité la question. Donc, si la base de données.loadpetabyteofdata () n'est pas rapide, je devrais diviser le mutex?
Pour la deuxième question. J'ai ajouté quelque chose. La fonction FUNC1 est une fonction de consommation de temps et une tunction 2 n'est pas. C'est pourquoi j'utilise deux mutiles pour eux.
Si ce n'est pas un problème (parce que c'est rapide et que la fractionnement ne vous donne aucune amélioration), ou pas si gros problème de payer un code un peu plus compliqué, je suggérerais que la priorité la plus élevée devrait être la lisibilité / la maintenabilité de votre code.
Avez-vous de multiples threads pouvant exécuter simultanément Func1 et Func2, et Func1 et Func2 peuvent être exécutés en toute sécurité simultanément? Dans ce cas Oui, utilisez deux mutiles séparés
D'accord merci. Oui, et dans Func2 uniquement si une condition est vraie, la fonction ira à la partie critique de la variable B. J'ai à nouveau mis à jour la question 2.
À propos de votre première question: Si les sections critiques A et B consomment du temps (et de l'indépendance), alors que deux sections distinctes aide deux threads à les exécuter simultanément. Donc, oui, dans certains cas, cela peut améliorer la performance.
À propos de votre deuxième Q: Pour les sections critiques légères, je vous recommande toujours de les mettre sous la même serrure. Avoir moins de serrures aide à éviter que les blocages se produisent en raison de l'erreur des programmeurs également.
Mais Func1 () prend beaucoup de temps et que Func2 n'est pas. La chose que je considère, c'est que si j'utilise le même mutex pour Func1 et Func2, Func2 doit attendre l'ensemble de la fonction Func1 plutôt que de la variable B.
@Gavin Xu Si Func1 prend du temps et que Func2 n'est pas, cela signifie que la section critique pour A est de prendre du temps. Donc, dans ce cas, il vaut mieux ne pas utiliser le même mutex pour Func1 et Func2.
La règle de base est de tenir la serrure aussi peu de temps que possible. Le profilage que vous ne vous dira que si vous gagnez ou non.
"Est-ce que cela améliorera mes performances de code?" - Pourquoi ne pouvez-vous pas le tester?
Je l'ai testé et la différence est trop petite. Il est difficile de voir les coûts de temps et cela pourrait à cause de mes cas de test. Et je n'ai aucune idée de la manière dont la performance de Mutex fonctionne, la seule chose que je sais, c'est de rendre la section critique aussi petite que possible. Mais je veux savoir pourquoi et un principe de comment devrais-je mettre en œuvre le mutex.
Pourquoi appelez-vous
mutex.lock () etmutex.unlock () manuellement, au lieu d'utiliser un verrou parfait commeunique_lock ouououououLock_Guard ? Ceci est un anti-motif .J'utilise simplement le code simple pour montrer comment fonctionne la logique. Je veux savoir comment fonctionne de niveau inférieur ici. Ce n'est pas mon vrai code.