Pourquoi passer mutex comme paramètre à une fonction appelée par un fil?

Je crois que vous pouvez avoir un mutex déclaré dans la fonction appelée elle-même ou peut-être a déclaré un membre de la classe ou mondial. Quelqu'un peut expliquer?

la création d'une nouvelle mutex à l'entrée protège rien.

si vous considérez la déclaration d'une statique (ou global) mutex pour protéger les non-membres statiques, alors vous pouvez aussi bien écrire le programme comme un seul programme multi-threadé (ok, il y a quelques cas particuliers). une statique de la serrure serait de bloquer tous les threads, mais (en supposant concours); il est équivalent à "un maximum d'un seul thread peut fonctionner dans cette méthode, le corps en une seule fois". la déclaration d'une statique mutex pour protéger les données statiques sont beaux. comme David Rodriguez - dribeas formulée de manière succincte dans une autre réponse, les commentaires de: "Le mutex doit être au niveau des données qui sont protégés".

vous peut déclarer une variable de membre par exemple, qui devrait prendre la forme généralisée:

class t_object {
public:
    ...
    bool getData(t_data& outData) {
        t_lock_scope lock(this->d_lock);
        ...
        outData.set(someValue);
        return true;
    }

private:
    t_lock d_lock;
};

cette approche est très bien, et dans certains cas idéal. il a de sens que dans la plupart des cas, lorsque vous êtes à la construction d'un système où les instances de l'intention à l'abrégé de verrouillage mécanique et les erreurs de leurs clients. un inconvénient est qu'il peut exiger plus d'acquisitions, et il nécessite généralement plus complexes mécanismes de verrouillage (par exemple réentrant). en plus des acquisitions: le client peut savoir qu'une instance est utilisé dans un seul fil de discussion: pourquoi serrure à tous dans ce cas? ainsi, un tas de petits threads méthodes d'introduire une surcharge importante. avec dispositif de verrouillage, vous voulez obtenir dans et hors des zones protégées les plus brefs délais (sans introduire de nombreuses acquisitions), de sorte que les sections critiques sont souvent des opérations plus importantes que la moyenne.

si l'interface publique nécessite ce verrou comme un argument (comme dans votre exemple), c'est un signal que votre conception peut être simplifié par la privatisation de verrouillage (la prise de fonction de l'objet dans un thread de manière sûre, plutôt que de passer le verrouillage de l'extérieur, tenue de ressources).

à l'aide d'un (ou lié ou associé) de verrouillage, vous pouvez éventuellement réduire les acquisitions (ou bloqué). cette approche permet également d'ajouter de verrouillage à une instance après le fait. il permet également au client de configurer la façon dont la serrure fonctionne. le client peut utiliser moins de verrous par le partage (parmi un ensemble d'instances). même un simple exemple de composition peut illustrer cela (supportant à la fois les modèles):

class t_composition {
public:
    ...
private:
    t_lock d_lock; //<< name and data can share this lock
    t_string d_name;
    t_data d_data;
};

compte tenu de la complexité de certains multithread systèmes, en poussant la responsabilité de la bonne fermeture sur le client peut être une très mauvaise idée.

les deux modèles (lié et en tant que membre de la variable) peut être utilisé efficacement. ce qui est mieux dans un scénario donné, varie en fonction du problème.

OriginalL'auteur justin