CMutex::Lock vs CSingleLock::Lock

J'ai été mis à contribution pour soutenir un code existant, et je vois des choses qui me rayer de ma tête dans la confusion. Dans certaines sections de code, je ne vois qu'une instance de la classe utilise un CMutex exemple pour synchroniser l'exécution de la méthode. Par exemple

class CClassA : public CObject
{
public:
   void DoSomething();

private:
   CMutex m_mutex;
}

void CClassA::DoSomething()
{
   m_mutex.Lock();

   //...logic...

   m_mutex.Unlock();
}

Ailleurs dans le même projet que je trouve que le code est à l'aide d'un CSingleLock

class CClassB : public CObject
{
public:
   void DoSomething();

private:
   CCriticalSection m_crit;
}

void CClassB::DoSomething()
{
   CSingleLock lock(&m_crit);
   lock.Lock();

   //...logic...

   lock.Unlock();
}

Après examen de La documentation MSDN pour la synchronisation, il semblerait que CClassB est la mise en œuvre de l'conseillé méthode, mais il n'est pas clair pour moi ce que le danger est dans la mise en œuvre utilisé par CClassA. Aussi loin que je peux dire, la seule différence entre les deux méthodes est que CSingleLock a l'avantage de RAII, de sorte que le verrou est libéré automatiquement lors de l'exécution de sorties portée. Existe-il d'autres avantages /inconvénients soit pour la mise en œuvre?

Pour ajouter un peu de contexte, l'une de mes préoccupations est de savoir si l'utilisation de CSingleLock::Verrou a subtilement comportement différent. Par exemple, lorsque le même thread pourrait être en mesure d'appeler CMutex::Verrouiller plusieurs fois (puisqu'il possède déjà la serrure), un appel à CSingleLock::Verrou sur la même instance de CSingleLock va bloquer. Je suis également préoccupé de ce que j'ai peut-être dans une situation où un CSingleLock est la gestion d'un CCriticalSection, mais que CCriticalSection a la méthode de Déverrouillage appelé directement.

OriginalL'auteur JadeMason | 2011-05-19

  1. 2

    En général mutex peut être utilisé pour contrôler le thread de l'accès à l'ensemble des processus par l'intermédiaire d'un mutex nommé alors que les sections critiques sont seulement pour la synchronisation de thread accès dans le même espace de processus.

    Aucune de ces classes vraiment obtenir le bénéfice de l'RAII sans emballage parce que, dans ce cas, vous n'aurait pas besoin d'appeler explicitement verrouiller ou déverrouiller. Prenez l'exemple de ce peu de pseudo-code à l'aide d'un coup de pouce mutex lock ...

    void DoSomething()
{
  //construction acquires lock on mutex
  boost::scoped_lock lock(&aBoostMutex);

  //...

} //end scope - object is destroyed and lock is released

    Maintenant, je dirais que vous devriez éviter CMutex, CCritalSection, CSemaphore, et CEvent parce que les implémentations sont un peu cassé ou tout au moins inférieur à d'autres bibliothèques comme boost. Par exemple:

    • Déterminer si un délai d'attente à partir d'un abandon mutex est impossible parce que la mise en œuvre des contrôles valeur de retour seulement pas la raison.
    • Pas réentrant verrouille à l'aide de CSingleLock sorte de récursivité à l'origine de problèmes.
    • Incapacité d'avoir un événement nommé entre les processus

    Selon ce que vous êtes chargé de vous pourriez avoir l'occasion de s'éloigner de la MFC wrappers sur les API de windows et la mise en œuvre de votre propre atomique de serrures ou utiliser quelque chose comme boost ou C++0x fonctionnalités comme std::mutex qui ne sont pas seulement de meilleures implémentations mais de fournir un support multi-plateforme.

    Malheureusement, je suis bloqué avec les MFC. Ma question était de moins en moins à propos de la différence entre CMutex et CCriticalSection, et plus sur la différence entre CSyncObject::Lock et CSingleLock::Lock. Après avoir fait un peu plus de recherche, il semble que CSingleLock se comporte de la même façon pour le boost::scoped_lock vous montrer ci-dessus (les appels de Déverrouillage sur le destructeur). Je ne savais pas CSingleLock empêché la récursivité, je suppose que chaque nouvelle instance sur la pile de gérer de façon indépendante.
    CSyncObject les appels de l'api Windows WaitForSingleObject sous les couvertures pour autant que je sais et ne peut pas être utilisé directement. C'est la classe de base de l'interface que CMutex dérive de sorte qu'il est utilisé lorsque vous ne CMutex::Lock(); sur votre instance. CSingleLock est votre CCriticalSection manipulateur qui est en béton et peut être utilisé comme un champ de verrouillage avec peu d'emballage. Comme mentionné précédemment, bien qu'il existe certains problèmes de conception avec ces objets de sorte qu'ils devraient être évités flounder.com/avoid_mfc_syncrhonization.htm
    Pour les futurs lecteurs, CSingleLock a un constructeur paramètre qui va l'amener à être verrouillé sur la construction. L'OP est l'exemple n'est pas à l'utiliser, de quelle sorte de défaites de la principale raison pour utiliser un CSingleLock.

    OriginalL'auteur AJG85

  2. 2

    Une section critique n'est visible à l'/utilisable par les threads à l'intérieur d'un seul et même processus. Un mutex peut être rendue visible à travers un certain nombre de processus (généralement par la création d'un mutex nommé). Ce que vous avez indiqué ci-dessus n'est pas assez pour dire si ce est pourquoi ils ont tous les deux, mais c'est une possibilité.

    À partir de ce que je peux dire, ce code n'a jamais une nécessité pour la synchronisation qui traverse les limites du processus. Cela me mène à croire que le CMutex dans CCLassA pourrait être remplacé par un CCriticalSection.

    OriginalL'auteur Jerry Coffin