Reicht es aus, eine Funktion als transaction_safe zu deklarieren, damit sie thread-sicher verwendet werden können?

Question

Ist genug, nur um alle Funktionen als transaction_safe in einigen meiner Klasse zu deklarieren, so kann es als threadsicher in Transaktionen atomic_noexcept, atomic_cancel, atomic_commit von Experimental Transactional Memory TS verwendet werden?

Wie bekannt gibt es Transactional Memory TS (ISO/IEC TS 19841: 2015) in den experimentellen C++ - Standardbibliotheken. Einfache Beispiele sind hier: http://en.cppreference.com/w/cpp/language/transactional_memory

Auch gibt es technische Spezifikation für die C++ Erweiterungen für Transactional Memory: http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2015/n4514.pdf

Seite 34:

23.4 Associative containers [associative] 
23.4.4 Class template map [map] 
23.4.4.1 Class template map overview [map.overview] 

In 23.4.4.1 [map.overview], add "transaction_safe" to the declarations of all 
variants of the begin and end member functions and to 
the declarations of size, max_size, and empty. 

D.h. Wenn Transactional Memory sich dem C++ Standard verschreibt, können wir dann einfach so etwas tun und wird es Thread-sicher? https://godbolt.org/g/UcV4wI

Und genug nur alle Funktionen wie transaction_safe in einigen meiner Klasse, so seine Dose zu erklären:

#include<map> 
#include<thread> 

std::map<int, int> m; 

int main() { 

std::thread t1([&m]() { 
    atomic_cancel 
    { 
    m[1] = 1; // thread-safe 
    } 
}); 

t1.join(); 

return 0; 
} 

Leider kann ich nicht Beispiel mit atomic_cancel {} sogar mit Schlüssel -fgnu-tm auf GCC 6.1 reproduzieren als thread-safe verwendet werden - wenn ich seinen in scope nennen werde: atomic_cancel { obj.func(); }?

Answer 1

Die Verbindung-Anweisung in einem atomaren Block wird keine Funktion auszuführen jeden Ausdruck oder eine Anweisung oder rufen erlaubt, die nicht transaction_safe

std::map<int, int>::operator[] wäre nicht so ist, ein Verfahren ist transaction_safe Sie könnten es nicht in atomic_cancel aufrufen. Es wäre ein Kompilierzeitfehler.