Si un mutex est défini dans une fonction, sa serrure s'applique-t-elle aux fonctions appelées à partir de cette fonction? IE
Class Foo; Foo foo1, foo2; (In thread 1) foo1.bar(); (In thread 2) foo2.bar();
3 Réponses :
Un mutex est quelque chose que vous attrapez et arrêterons tout autre fil essayant de l'attraper jusqu'à ce que vous le libérez du fil à saisir.
Dans votre question, vous avez une fonction FAVOCATION d'une instance mutex. Cela ne suffit pas pour le verrouiller. Vous devez appeler spécifiquement mutex.lock () (en Qt, mais aussi en général, à moins que vous n'utilisiez Pthread, dans ce cas, utilisez pthread_mutex_lock et amusez-vous avec des trucs dépendants de basse plate-forme. Qt le résume très bien). P >
Voici un exemple avec qt p> une fois que vous avez obtenu la serrure, l'appel à g () sera effectué à partir du fil qui a obtenu la serrure, alors sera seul dans cet appel Si c'est le seul moyen de atteindre G (), vous êtes synchronisé sur cet accès. P > Pour la deuxième partie de votre question, si le mutex est un attribut d'instance, ils seront deux mutiles différents. Vous devrez déclarer et instancier une instance de classe Mutex et le faire appeler votre verrouillage. Dans ce cas, toute tentative d'appeler une méthode dans la classe qui verrouille la classe Mutex sera efficacement synchronisée, ce qui signifie qu'aucun thread ne sera exécuté que la méthode ensemble. P> Par exemple (je n'ai pas qt , donc je ne peux pas compiler ce code et j'ai arrêté de coder avec elle il y a 2 ans, il ne pouvait donc pas fonctionner) p> OK, dans ce cas, supposons que vous ayez deux threads , 1 et 2, et deux instances de la classe FOO, A et B. Supposons que le fil 1 appelle A.method () et thread 2 appels b.method (). Dans ce cas, les deux mautexes sont des instances différentes, chaque thread exécutera l'appel, indépendamment et exécutera en parallèle. P> Supposons que vous ayez deux threads, 1 et 2 et une instance de la classe FOO qui est partagé entre les deux threads. Si le fil 1 appelle A.method () puis filever 2 appels A.method (), le thread 2 s'arrêtera et attendra jusqu'à ce que le verrou de mutex soit libéré. P> Enfin, P> class Foo {
public:
void method(void) {
mutex.lock();
cout << "method called";
// long computation
mutex.unlock();
}
private:
static QMutex mutex;
};
QMutex Foo::mutex;
Désolé, j'ai fait une très mauvaise tentative de pseudocode. Juste la corrigé. Votre réponse pour la première partie était exactement ce que je me demandais sur, merci!
Votre mutex est instaré localement sur la pile. Donc, un appel à F () d'un thread sera verrouillé sa instance em> du mutex. Tout autre appel à F () d'un autre fil verrouille le sien. Donc, une condition de course pourrait avoir lieu avec des données accessibles de g ()! Même difficile, vous l'appelez sur la même instance de classe: MyClass foo;
(In thread 1) foo->f();
(In thread 2) foo->f();
Donc, si j'ai des données, je veux verrouiller des instances spécifiques de FOO :: F (), devrais-je instancier le mutex comme des données de classe non statiques?
Eh bien, je suppose que cela devrait faire l'affaire. Ensuite, n'importe quel appel de l'instance «FOO» à partir de n'importe quel fil de mon exemple empêchera l'accès simultané. (Mais pas de 2 instances différentes bien sûr)
Dans votre exemple, vous ne verrouillez pas réellement le mutex, il n'empêchera donc pas de différents threads d'accéder à la fonction en même temps. De plus, vous déclarez le mutex localement à l'intérieur de la fonction, de sorte que chaque appel de fonction utilise un objet mutex local différent. Même si ce mutex serait verrouillé, chaque appel de fonction verrouille un objet mutex différent, sans empêcher l'accès simultané.
Une meilleure stratégie serait une configuration comme ceci: p> Dans ce cas mutex code> est verrouillé aussi longtemps que
ml code> existe, donc aussi pendant le temps que le fil dépense à l'intérieur
g () code>. Si un autre thread appelle
f () code> Pendant ce temps, il serait bloqué dans la création de son objet
ml code> jusqu'à ce que le premier thread soit la fonction et que le nouveau thread puisse obtenir la serrure sur
mutex code>. p> p>