Ist meine Double-Checked Locking Pattern-Implementierung richtig?

Question

Ein Beispiel in Meyers Buch Effektive Moderne C++, Punkt 16.

in einer Klasse-Caching ein teurer zu berechnen int, könnten Sie versuchen, ein Paar std :: Atom avriables verwenden statt ein Mutex:

class Widget { 
public: 
    int magicValue() const { 
     if (cachedValid) { 
      return cachedValue; 
     } else { 
      auto val1 = expensiveComputation1(); 
      auto val2 = expensiveComputation2(); 

      cachedValue = va1 + val2; 
      cacheValid = true; 
      return cachedValue; 
     } 
    } 
private: 
    mutable std::atomic<bool> cacheValid { false }; 
    mutable std::atomic<int> cachedValue; 
}; 

Dies funktioniert, aber manchmal wird es viel härter zu arbeiten, als es should.Consider: ein Thread Widget ruft :: magicValue, sieht cacheValid als false, führt die zwei teuren Berechnungen durch und ordnet ihre Summe CachedValud zu. An diesem Punkt, ein zweiter Thread calss Widget :: magicValue, sieht auch cacheValid als falsch, und führt somit aus den gleichen teuren Berechnungen, die der erste Thread nur abgeschlossen hat.

Dann gibt er eine Lösung mit Mutex:

class Widget { 
public: 
    int magicValue() const { 
     std::lock_guard<std::mutex> guard(m); 
     if (cacheValid) { 
      return cachedValue; 
     } else { 
      auto val1 = expensiveComputation1(); 
      auto val2 = expensiveComputation2(); 

      cachedValue = va1 + val2; 
      cacheValid = true; 
      return cachedValue; 
     } 
    } 
private: 
    mutable std::mutex m; 
    mutable bool cacheValid { false }; 
    mutable int cachedValue; 
}; 

Aber ich glaube, die Lösung nicht so effecient ist, halte ich Mutex zu kombinieren und Atom bilden ein Doppel-Karomuster Sperren als unten.

class Widget { 
public: 
    int magicValue() const { 
     if (!cacheValid) { 
      std::lock_guard<std::mutex> guard(m); 
      if (!cacheValid) { 
       auto val1 = expensiveComputation1(); 
       auto val2 = expensiveComputation2(); 

       cachedValue = va1 + val2; 
       cacheValid = true; 
      } 
     } 
     return cachedValue; 
    } 
private: 
    mutable std::mutex m; 
    mutable std::atomic<bool> cacheValid { false }; 
    mutable std::atomic<int> cachedValue; 
}; 

Weil ich ein Neuling in Multi-Thread-Programmierung bin, so möchte ich wissen:

• Ist mein Code richtig?
• Ist die Leistung besser?

EDIT:

---

den Code behoben. (! CachedValue) wenn -> if (cacheValid!)

Answer 1

Recht mein Code?

Ja. Die Anwendung des Double-Checked Locking Patterns ist korrekt. Aber sehen Sie unten für einige Verbesserungen.

Ist die Leistung besser?

Wenn mit vollständig gesperrten Variante (2. in Ihrem Beitrag) im Vergleich, hat es meist eine bessere Leistung, bis magicValue() nur einmal aufgerufen wird (aber auch in diesem Fall Leistungsverluste sind vernachlässigbar klein).

Im Vergleich mit Lockless-Variante (1. in Ihrem Beitrag), zeigt Ihr Code eine bessere Leistung, bis Wert Berechnung schneller ist als warten auf Mutex.

Z. B. Summe von 10 Werten ist (in der Regel) schneller als auf Mutex warten. In diesem Fall ist die erste Variante vorzuziehen. Von der anderen Seite, 10 liest aus Datei ist langsamer als warten auf Mutex, so ist Ihre Variante besser als 1st.

---

Eigentlich gibt es einfache improvemnts, um Ihren Code, der es schneller zu machen (zumindest auf einigen Maschinen) und Code-Verständnis verbessern:

1. cachedValue Variable nicht atomar erfordert semantische bei alle. Es wird durch cacheValid Flag geschützt, welche Atomizität die ganze Arbeit macht. Darüber hinaus kann ein einzelnes atomares Flag mehrere nicht atomare Werte schützen.

2. Auch als https://stackoverflow.com/a/30049946/3440745 in dieser Antwort erwähnt, wenn der Zugriff auf cacheValid Flag Sie sequenzielle Konsistenz, um nicht brauchen (die standardmäßig angewandt, wenn Sie einfach Atom-Variable lesen oder schreiben), Release-acquire, um ausreichend ist.

---

class Widget { 
public: 
    int magicValue() const { 
     //'Acquire' semantic when read flag. 
     if (!cacheValid.load(std::memory_order_acquire)) { 
      std::lock_guard<std::mutex> guard(m); 
      // Reading flag under mutex locked doesn't require any memory order. 
      if (!cacheValid.load(std::memory_order_relaxed)) { 
       auto val1 = expensiveComputation1(); 
       auto val2 = expensiveComputation2(); 

       cachedValue = va1 + val2; 
       // 'Release' semantic when write flag 
       cacheValid.store(true, std::memory_order_release); 
      } 
     } 
     return cachedValue; 
    } 
private: 
    mutable std::mutex m; 
    mutable std::atomic<bool> cacheValid { false }; 
    mutable int cachedValue; // Atomic isn't needed here. 
}; 

Answer 2

Es ist nicht korrekt:

int magicValue() const { 
    if (!cachedValid) { 

     // this part is unprotected, what if a second thread evaluates 
     // the previous test when this first is here? it behaves 
     // exactly like in the first example. 

     std::lock_guard<std::mutex> guard(m); 
     if (!cachedValue) { 
      auto val1 = expensiveComputation1(); 
      auto val2 = expensiveComputation2(); 

      cachedValue = va1 + val2; 
      cachedValid = true; 
     } 
    } 
    return cachedValue; 

Answer 3

Wie HappyCactus wies darauf hin, die zweite Prüfung if (!cachedValue) tatsächlich if (!cachedValid) sein sollte. Abgesehen von diesem Tippfehler denke ich, dass Ihre Demonstration des Double-Checked Locking Patterns korrekt ist. Ich denke jedoch, dass es unnötig ist, std::atomic auf zu verwenden. Der einzige Ort, an dem cachedValue geschrieben wird, ist cachedValue = va1 + val2;. Bevor es fertig ist, wird kein Thread jemals die Anweisung return cachedValue; erreichen, die die einzige Stelle ist, an der gelesen wird. Daher ist es unmöglich, dass ein Schreiben und ein Lesen gleichzeitig erfolgt. Und es gibt kein Problem mit gleichzeitigen Lesevorgängen.

Answer 4

Sie können Ihre Lösung etwas effizienter machen, indem Sie die Speicheranforderungen reduzieren. Die Reihenfolge der sequentiellen Konsistenzspeicher für atomare Operationen ist hier nicht erforderlich.

Der Leistungsunterschied kann auf x86 vernachlässigbar sein, ist aber auf ARM bemerkbar, da die sequenzielle Konsistenzspeicherordnung auf ARM teuer ist. Weitere Details finden Sie unter “Strong” and “weak” hardware memory models by Herb Sutter.

Vorgeschlagene Änderungen:

class Widget { 
public: 
    int magicValue() const { 
     if (cachedValid.load(std::memory_order_acquire)) { // Acquire semantics. 
      return cachedValue; 
     } else { 
      auto val1 = expensiveComputation1(); 
      auto val2 = expensiveComputation2(); 

      cachedValue = va1 + val2; // Non-atomic write. 

      // Release semantics. 
      // Prevents compiler and CPU store reordering. 
      // Makes this and preceding stores by this thread visible to other threads. 
      cachedValid.store(true, std::memory_order_release); 
      return cachedValue; 
     } 
    } 
private: 
    mutable std::atomic<bool> cacheValid { false }; 
    mutable int cachedValue; // Non-atomic. 
};