https://llvm.org/bugs/show_bug.cgi?id=27658
Bug ID: 27658
Summary: std::mutex should be trivially destructible
Product: libc++
Version: unspecified
Hardware: PC
OS: All
Status: NEW
Severity: normal
Priority: P
Component: All Bugs
Assignee: unassignedclangb...@nondot.org
Reporter: e...@efcs.ca
CC: llvm-bugs@lists.llvm.org, mclow.li...@gmail.com
Classification: Unclassified
Currently std::mutex has a constexpr constructor, but a non-trivial
destruction.
The constexpr constructor is required to ensure the construction of a mutex
with static storage duration happens at compile time, during constant
initialization, and not during dynamic initialization.
This means that static mutex's are always initialized and can be used safely
during dynamic initialization without the "static initialization order fiasco".
A trivial destructor is important for similar reasons. If a mutex is used
during dynamic initialization it might also be used during program termination.
If a static mutex has a non-trivial destructor it will be invoked during
termination. This can introduce the "static deinitialization order fiasco".
Additionally, function-local statics emit a guard variable around non-trivially
destructible types. This results in horrible codegen and adds a runtime cost to
every call to that function. non-local static's also result in slightly worse
codegen but it's not as big of a problem.
Example codegen can be found here: https://goo.gl/3CSzbM
For these reasons I believe we should change 'std::mutex' to be trivially
destructible (when possible). This means *NOT* invoking
"pthread_mutex_destroy(...)" in the destructor.
I believe is a safe change on some pthread implementations. The main purpose of
"pthread_mutex_destroy" is to set the lock to an invalid value, allowing
use-after-free to be diagnosed. AFAIK mutex's initialized with
"PTHREAD_MUTEX_INITIALIZER" own no resources and so omitting the call will not
cause leaks.
On other pthread implementations this change will not be possible.
Note that std::mutex::~mutex is defined in the dylib, so such a change would
have to ensure we continue to define it there.
--
You are receiving this mail because:
You are on the CC list for the bug.
_______________________________________________
llvm-bugs mailing list
llvm-bugs@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
