This is an archive of the discontinued LLVM Phabricator instance.

Fix PR30202 - notify_all_at_thread_exit seg faults if run from a raw pthread context.
ClosedPublic

Authored by EricWF on Sep 1 2016, 2:31 PM.

Details

Summary

This patch allows threads not created using std::thread to use std::notify_all_at_thread_exit by ensuring the TL state has been initialized within std::notify_all_at_thread_exit.

Additionally this patch "fixes" a potential oddity in __thread_local_pointer::reset(pointer), which would previously delete the old thread local data. However there should *never* be old thread local data because pthread *should* null it out on thread exit. Unfortunately it's possible that pthread failed to do this according to the spec:

Upon key creation, the value NULL shall be associated with the new key in all active threads. Upon thread creation, the value NULL shall be associated with all defined keys in the new thread.

An optional destructor function may be associated with each key value. At thread exit, if a key value has a non-NULL destructor pointer, and the thread has a non-NULL value associated with that key, the value of the key is set to NULL, and then the function pointed to is called with the previously associated value as its sole argument. The order of destructor calls is unspecified if more than one destructor exists for a thread when it exits.

If, after all the destructors have been called for all non-NULL values with associated destructors, there are still some non-NULL values with associated destructors, then the process is repeated. If, after at least {PTHREAD_DESTRUCTOR_ITERATIONS} iterations of destructor calls for outstanding non-NULL values, there are still some non-NULL values with associated destructors, implementations may stop calling destructors, or they may continue calling destructors until no non-NULL values with associated destructors exist, even though this might result in an infinite loop.

However if pthread fails to delete the value it is probably incorrect for us to do it. Destroying the value performs all of the "at thread exit" actions registered with it but we are way past "at thread exit".

Diff Detail

Event Timeline

EricWF updated this revision to Diff 70067.Sep 1 2016, 2:31 PM
EricWF retitled this revision from to Fix PR30202 - notify_all_at_thread_exit seg faults if run from a raw pthread context..
EricWF updated this object.
EricWF added reviewers: mclow.lists, bcraig.
EricWF added a subscriber: cfe-commits.
bcraig added inline comments.Sep 2 2016, 6:23 AM
src/condition_variable.cpp
86

The standard synopsis of notify_all_at_thread_exit in the standard doesn't have a "Throws:" clause. I think that means that this is non-conformant.

There is some phrasing in 30.2.2 [thread.req.exception]:

Failure to allocate storage shall be reported as described in 17.6.5.12 [res.on.exception.handling].

But I don't see wording in that section that gives permission to throw from functions without Throws clauses.

From a user perspective, I generally expect my synchronization primitives to be no-throw. I don't know if it is really possible to provide that guarantee with notify_all_at_thread_exit though, especially if we want it to work outside of a std::thread.

EricWF added inline comments.Sep 2 2016, 12:22 PM
src/condition_variable.cpp
86

[res.on.exception.handling]/p4

Destructor operations defined in the C ++ standard library shall not throw exceptions. Every destructor
in the C ++ standard library shall behave as if it had a non-throwing exception specification. Any other
functions defined in the C ++ standard library that do not have an exception-specification may throw
implementation-defined exceptions unless otherwise specified. [188] An implementation may strengthen this
implicit exception-specification by adding an explicit one.

And the relevant note:

  1. In particular, they can report a failure to allocate storage by throwing an exception of type bad_alloc, or a class derived

from bad_alloc (18.6.3.1). Library implementations should report errors by throwing exceptions of or derived from the standard
exception classes (18.6.3.1, 18.8, 19.2).

So throwing std::bad_alloc is allowed, as it is almost everywhere in the STL. Also the function already allocates memory to store the new entry.

bcraig edited edge metadata.Sep 2 2016, 12:32 PM

LGTM

src/condition_variable.cpp
86

Yet again, I find that reading comprehension with regards to the standard isn't my strong suit :). I got to "Destructor operations" in p4 and stopped reading.

I will still wish for a noexcept version of this function, but it's a pretty impractical wish. The implementation you have here is fine.

EricWF accepted this revision.Sep 3 2016, 1:15 AM
EricWF added a reviewer: EricWF.
This revision is now accepted and ready to land.Sep 3 2016, 1:15 AM
EricWF closed this revision.Sep 3 2016, 1:15 AM