Warum gibt es keine Bereichssperren für mehrere Mutexe in C++ 0x oder Boost.Thread?

Question

C++ 0x Thread-Bibliothek oder Boost.thread definieren Nicht-Mitglied variadic Template-Funktion, die alle Sperre sperren Vermeidung von Dead-Lock.

Während diese Funktion die Deadlock-Hilfe vermeidet, enthält der Standard nicht die zugehörige Bereichssperre zum Schreiben von Ausnahme-Sicherheitscode.

{ 
    std::lock(l1,l2); 
    // do some thing 
    // unlock li l2 exception safe 
} 

Das bedeutet, dass wir einen anderen Mechanismus als try-catch-Block zu machen Ausnahme sicheren Code oder definieren eigene scoped Sperre für mehrere mutexes uns oder sogar tun, dass

{ 
    std::lock(l1,l2); 
    std::unique_lock lk1(l1, std::adopted); 
    std::unique_lock lk2(l2, std::adopted); 
    // do some thing 
    // unlock li l2 on destruction of lk1 lk2 
} 

Warum die Standard verwenden müssen kein scoped Sperre auf mehrere mutexes desselben Typs enthält, wie beispielsweise

{ 
    std::array_unique_lock<std::mutex> lk(l1,l2); 
    // do some thing 
    // unlock l1 l2 on destruction of lk 
} 

oder Tupel von mutexes

{ 
    std::tuple_unique_lock<std::mutex, std::recursive_mutex> lk(l1,l2); 
    // do some thing 
    // unlock l1 l2 on destruction of lk 
} 

Ist etwas falsch am Design?

---

Aktualisiert: Beschreibung der Standard

template <class L1, class L2, class... L3> void lock(L1&, L2&, L3&...); 

Benötigt: Jede Vorlage Parametertyp legt die Mutex Anforderungen erfüllen, mit Ausnahme, dass ein Anruf Sperre try_-() kann eine Ausnahme auslösen . [Hinweis: Die Template-Vorlage unique_lock erfüllt diese Anforderungen, wenn sie in geeigneter Weise instanziiert wird. -end note]

Effekte: Alle Argumente werden durch eine Folge von Aufrufen von lock(), try_lock() oder unlock() für jedes Argument gesperrt. Die Reihenfolge der Aufrufe darf nicht zu einem Deadlock führen, ist aber ansonsten nicht spezifiziert. [Hinweis: Ein Deadlock-Vermeidungsalgorithmus wie "try-and-back-off" muss verwendet werden, der spezifische Algorithmus wird jedoch nicht angegeben, um übermäßige Implementierungen zu vermeiden. -end note] Wenn ein Aufruf von lock() oder try_lock() eine Ausnahme auslöst, sollte unlock() für jedes Argument aufgerufen werden, das durch einen Aufruf von lock() oder try_lock() gesperrt wurde.

---

Ich habe die Antwort akzeptieren. Ich verstehe, dass der Hauptgrund ist, weil es nicht genug Zeit gibt, um die C++ 0x Thread-Bibliothek besser zu machen. Ich hoffe, dass TR2 viel mehr Dinge beinhaltet.

Answer 1

Ich denke, dass durch die Bereitstellung defer_lock_t (und adopt_lock_t) die Erwartung, dass die Nutzung wie Ihr zweites Beispiel sein wird, ist, oder wahrscheinlich eher wie:

std::unqiue_lock ul1(l1, std::deferred); 
std::unique_lock ul2(l2, std::deferred); 
std::lock(ul1, ul2); 

Dies ist Ausnahme sicher und alles, was gute Sachen.

Ich kann sicherlich nicht vorgeben, die Köpfe der Designer zu kennen, aber ich schätze, dass sie sich bemühen, ein Minimum an tragbaren, sicheren, primitiven zu bieten.Ein Mehrfachverriegelungstyp ist nur so viel Vereisung, und es ist eine Vereisung, wenn im Standard spezifiziert und entworfen werden muss, oder in boost.thread, die Vereisung, die implementiert werden muss (und natürlich muss sich der Standard letztendlich Sorgen machen) Implementierung, schauen Sie, was mit dem Export passiert ist).

Answer 2

Wenn Sie ein Objekt erstellen, das mehrere Sperren sperrt, werden keine Deadlocks vermieden, sondern nur diese einzeln gesperrt. Sie können nicht zwei Schlösser gleichzeitig sperren. Es sei denn, Sie verwenden zwei Fäden, die den Punkt besiegen. Dies gilt auch, wenn Sie sie in die gleiche Aussage setzen.