llvm-project/libcxx/include/thread

Ignoring revisions in .git-blame-ignore-revs. Click here to bypass and see the normal blame view.

415 lines
11 KiB
Plaintext
Raw Normal View History

2010-05-12 03:42:16 +08:00
// -*- C++ -*-
//===--------------------------- thread -----------------------------------===//
//
// Part of the LLVM Project, under the Apache License v2.0 with LLVM Exceptions.
// See https://llvm.org/LICENSE.txt for license information.
// SPDX-License-Identifier: Apache-2.0 WITH LLVM-exception
2010-05-12 03:42:16 +08:00
//
//===----------------------------------------------------------------------===//
#ifndef _LIBCPP_THREAD
#define _LIBCPP_THREAD
/*
thread synopsis
namespace std
{
class thread
{
public:
class id;
typedef pthread_t native_handle_type;
thread() noexcept;
2010-05-12 03:42:16 +08:00
template <class F, class ...Args> explicit thread(F&& f, Args&&... args);
~thread();
thread(const thread&) = delete;
thread(thread&& t) noexcept;
2010-05-12 03:42:16 +08:00
thread& operator=(const thread&) = delete;
thread& operator=(thread&& t) noexcept;
2010-05-12 03:42:16 +08:00
void swap(thread& t) noexcept;
2010-05-12 03:42:16 +08:00
bool joinable() const noexcept;
2010-05-12 03:42:16 +08:00
void join();
void detach();
id get_id() const noexcept;
2010-05-12 03:42:16 +08:00
native_handle_type native_handle();
static unsigned hardware_concurrency() noexcept;
2010-05-12 03:42:16 +08:00
};
void swap(thread& x, thread& y) noexcept;
2010-05-12 03:42:16 +08:00
class thread::id
{
public:
id() noexcept;
2010-05-12 03:42:16 +08:00
};
bool operator==(thread::id x, thread::id y) noexcept;
bool operator!=(thread::id x, thread::id y) noexcept;
bool operator< (thread::id x, thread::id y) noexcept;
bool operator<=(thread::id x, thread::id y) noexcept;
bool operator> (thread::id x, thread::id y) noexcept;
bool operator>=(thread::id x, thread::id y) noexcept;
2010-05-12 03:42:16 +08:00
template<class charT, class traits>
basic_ostream<charT, traits>&
operator<<(basic_ostream<charT, traits>& out, thread::id id);
namespace this_thread
{
thread::id get_id() noexcept;
2010-05-12 03:42:16 +08:00
void yield() noexcept;
2010-05-12 03:42:16 +08:00
template <class Clock, class Duration>
void sleep_until(const chrono::time_point<Clock, Duration>& abs_time);
template <class Rep, class Period>
void sleep_for(const chrono::duration<Rep, Period>& rel_time);
} // this_thread
} // std
*/
#include <__config>
#include <iosfwd>
#include <__functional_base>
#include <type_traits>
#include <cstddef>
#include <functional>
#include <memory>
#include <system_error>
#include <chrono>
#include <__mutex_base>
#ifndef _LIBCPP_CXX03_LANG
#include <tuple>
#endif
#include <__threading_support>
Fix PR30202 - notify_all_at_thread_exit seg faults if run from a raw pthread context. 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". Reviewers: mclow.lists, bcraig, EricWF Subscribers: cfe-commits Differential Revision: https://reviews.llvm.org/D24159 llvm-svn: 280588
2016-09-03 16:07:40 +08:00
#include <__debug>
2010-05-12 03:42:16 +08:00
#if !defined(_LIBCPP_HAS_NO_PRAGMA_SYSTEM_HEADER)
2010-05-12 03:42:16 +08:00
#pragma GCC system_header
#endif
2010-05-12 03:42:16 +08:00
_LIBCPP_PUSH_MACROS
#include <__undef_macros>
#ifdef _LIBCPP_HAS_NO_THREADS
#error <thread> is not supported on this single threaded system
#else // !_LIBCPP_HAS_NO_THREADS
2010-05-12 03:42:16 +08:00
_LIBCPP_BEGIN_NAMESPACE_STD
template <class _Tp> class __thread_specific_ptr;
class _LIBCPP_TYPE_VIS __thread_struct;
class _LIBCPP_HIDDEN __thread_struct_imp;
class __assoc_sub_state;
_LIBCPP_FUNC_VIS __thread_specific_ptr<__thread_struct>& __thread_local_data();
class _LIBCPP_TYPE_VIS __thread_struct
{
__thread_struct_imp* __p_;
__thread_struct(const __thread_struct&);
__thread_struct& operator=(const __thread_struct&);
public:
__thread_struct();
~__thread_struct();
void notify_all_at_thread_exit(condition_variable*, mutex*);
void __make_ready_at_thread_exit(__assoc_sub_state*);
};
2010-08-28 04:10:19 +08:00
template <class _Tp>
class __thread_specific_ptr
{
[libcxx] Introduce an externally-threaded libc++ variant. This patch further decouples libc++ from pthread, allowing libc++ to be built against other threading systems. There are two main use cases: - Building libc++ against a thread library other than pthreads. - Building libc++ with an "external" thread API, allowing a separate library to provide the implementation of that API. The two use cases are quite similar, the second one being sligtly more de-coupled than the first. The cmake option LIBCXX_HAS_EXTERNAL_THREAD_API enables both kinds of builds. One needs to place an <__external_threading> header file containing an implementation of the "libc++ thread API" declared in the <__threading_support> header. For the second use case, the implementation of the libc++ thread API can delegate to a custom "external" thread API where the implementation of this external API is provided in a seperate library. This mechanism allows toolchain vendors to distribute a build of libc++ with a custom thread-porting-layer API (which is the "external" API above), platform vendors (recipients of the toolchain/libc++) are then required to provide their implementation of this API to be linked with (end-user) C++ programs. Note that the second use case still requires establishing the basic types that get passed between the external thread library and the libc++ library (e.g. __libcpp_mutex_t). These cannot be opaque pointer types (libc++ sources won't compile otherwise). It should also be noted that the second use case can have a slight performance penalty; as all the thread constructs need to cross a library boundary through an additional function call. When the header <__external_threading> is omitted, libc++ is built with the "libc++ thread API" (declared in <__threading_support>) as the "external" thread API (basic types are pthread based). An implementation (pthread based) of this API is provided in test/support/external_threads.cpp, which is built into a separate DSO and linked in when running the libc++ test suite. A test run therefore demonstrates the second use case (less the intermediate custom API). Differential revision: https://reviews.llvm.org/D21968 Reviewers: bcraig, compnerd, EricWF, mclow.lists llvm-svn: 281179
2016-09-12 05:46:40 +08:00
__libcpp_tls_key __key_;
2010-08-28 04:10:19 +08:00
// Only __thread_local_data() may construct a __thread_specific_ptr
// and only with _Tp == __thread_struct.
static_assert((is_same<_Tp, __thread_struct>::value), "");
__thread_specific_ptr();
friend _LIBCPP_FUNC_VIS __thread_specific_ptr<__thread_struct>& __thread_local_data();
2010-08-28 04:10:19 +08:00
__thread_specific_ptr(const __thread_specific_ptr&);
__thread_specific_ptr& operator=(const __thread_specific_ptr&);
_LIBCPP_HIDDEN static void _LIBCPP_TLS_DESTRUCTOR_CC __at_thread_exit(void*);
2010-08-28 04:10:19 +08:00
public:
typedef _Tp* pointer;
~__thread_specific_ptr();
_LIBCPP_INLINE_VISIBILITY
[libcxx] Introduce an externally-threaded libc++ variant. This patch further decouples libc++ from pthread, allowing libc++ to be built against other threading systems. There are two main use cases: - Building libc++ against a thread library other than pthreads. - Building libc++ with an "external" thread API, allowing a separate library to provide the implementation of that API. The two use cases are quite similar, the second one being sligtly more de-coupled than the first. The cmake option LIBCXX_HAS_EXTERNAL_THREAD_API enables both kinds of builds. One needs to place an <__external_threading> header file containing an implementation of the "libc++ thread API" declared in the <__threading_support> header. For the second use case, the implementation of the libc++ thread API can delegate to a custom "external" thread API where the implementation of this external API is provided in a seperate library. This mechanism allows toolchain vendors to distribute a build of libc++ with a custom thread-porting-layer API (which is the "external" API above), platform vendors (recipients of the toolchain/libc++) are then required to provide their implementation of this API to be linked with (end-user) C++ programs. Note that the second use case still requires establishing the basic types that get passed between the external thread library and the libc++ library (e.g. __libcpp_mutex_t). These cannot be opaque pointer types (libc++ sources won't compile otherwise). It should also be noted that the second use case can have a slight performance penalty; as all the thread constructs need to cross a library boundary through an additional function call. When the header <__external_threading> is omitted, libc++ is built with the "libc++ thread API" (declared in <__threading_support>) as the "external" thread API (basic types are pthread based). An implementation (pthread based) of this API is provided in test/support/external_threads.cpp, which is built into a separate DSO and linked in when running the libc++ test suite. A test run therefore demonstrates the second use case (less the intermediate custom API). Differential revision: https://reviews.llvm.org/D21968 Reviewers: bcraig, compnerd, EricWF, mclow.lists llvm-svn: 281179
2016-09-12 05:46:40 +08:00
pointer get() const {return static_cast<_Tp*>(__libcpp_tls_get(__key_));}
_LIBCPP_INLINE_VISIBILITY
2010-08-28 04:10:19 +08:00
pointer operator*() const {return *get();}
_LIBCPP_INLINE_VISIBILITY
2010-08-28 04:10:19 +08:00
pointer operator->() const {return get();}
Fix PR30202 - notify_all_at_thread_exit seg faults if run from a raw pthread context. 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". Reviewers: mclow.lists, bcraig, EricWF Subscribers: cfe-commits Differential Revision: https://reviews.llvm.org/D24159 llvm-svn: 280588
2016-09-03 16:07:40 +08:00
void set_pointer(pointer __p);
2010-08-28 04:10:19 +08:00
};
template <class _Tp>
void _LIBCPP_TLS_DESTRUCTOR_CC
2010-08-28 04:10:19 +08:00
__thread_specific_ptr<_Tp>::__at_thread_exit(void* __p)
{
2011-10-18 04:08:59 +08:00
delete static_cast<pointer>(__p);
2010-08-28 04:10:19 +08:00
}
template <class _Tp>
__thread_specific_ptr<_Tp>::__thread_specific_ptr()
{
int __ec =
__libcpp_tls_create(&__key_, &__thread_specific_ptr::__at_thread_exit);
if (__ec)
__throw_system_error(__ec, "__thread_specific_ptr construction failed");
2010-08-28 04:10:19 +08:00
}
template <class _Tp>
__thread_specific_ptr<_Tp>::~__thread_specific_ptr()
{
// __thread_specific_ptr is only created with a static storage duration
// so this destructor is only invoked during program termination. Invoking
// pthread_key_delete(__key_) may prevent other threads from deleting their
// thread local data. For this reason we leak the key.
2010-08-28 04:10:19 +08:00
}
template <class _Tp>
void
Fix PR30202 - notify_all_at_thread_exit seg faults if run from a raw pthread context. 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". Reviewers: mclow.lists, bcraig, EricWF Subscribers: cfe-commits Differential Revision: https://reviews.llvm.org/D24159 llvm-svn: 280588
2016-09-03 16:07:40 +08:00
__thread_specific_ptr<_Tp>::set_pointer(pointer __p)
2010-08-28 04:10:19 +08:00
{
Fix PR30202 - notify_all_at_thread_exit seg faults if run from a raw pthread context. 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". Reviewers: mclow.lists, bcraig, EricWF Subscribers: cfe-commits Differential Revision: https://reviews.llvm.org/D24159 llvm-svn: 280588
2016-09-03 16:07:40 +08:00
_LIBCPP_ASSERT(get() == nullptr,
"Attempting to overwrite thread local data");
[libcxx] Introduce an externally-threaded libc++ variant. This patch further decouples libc++ from pthread, allowing libc++ to be built against other threading systems. There are two main use cases: - Building libc++ against a thread library other than pthreads. - Building libc++ with an "external" thread API, allowing a separate library to provide the implementation of that API. The two use cases are quite similar, the second one being sligtly more de-coupled than the first. The cmake option LIBCXX_HAS_EXTERNAL_THREAD_API enables both kinds of builds. One needs to place an <__external_threading> header file containing an implementation of the "libc++ thread API" declared in the <__threading_support> header. For the second use case, the implementation of the libc++ thread API can delegate to a custom "external" thread API where the implementation of this external API is provided in a seperate library. This mechanism allows toolchain vendors to distribute a build of libc++ with a custom thread-porting-layer API (which is the "external" API above), platform vendors (recipients of the toolchain/libc++) are then required to provide their implementation of this API to be linked with (end-user) C++ programs. Note that the second use case still requires establishing the basic types that get passed between the external thread library and the libc++ library (e.g. __libcpp_mutex_t). These cannot be opaque pointer types (libc++ sources won't compile otherwise). It should also be noted that the second use case can have a slight performance penalty; as all the thread constructs need to cross a library boundary through an additional function call. When the header <__external_threading> is omitted, libc++ is built with the "libc++ thread API" (declared in <__threading_support>) as the "external" thread API (basic types are pthread based). An implementation (pthread based) of this API is provided in test/support/external_threads.cpp, which is built into a separate DSO and linked in when running the libc++ test suite. A test run therefore demonstrates the second use case (less the intermediate custom API). Differential revision: https://reviews.llvm.org/D21968 Reviewers: bcraig, compnerd, EricWF, mclow.lists llvm-svn: 281179
2016-09-12 05:46:40 +08:00
__libcpp_tls_set(__key_, __p);
2010-08-28 04:10:19 +08:00
}
2010-05-12 03:42:16 +08:00
template<>
struct _LIBCPP_TEMPLATE_VIS hash<__thread_id>
2010-05-12 03:42:16 +08:00
: public unary_function<__thread_id, size_t>
{
_LIBCPP_INLINE_VISIBILITY
size_t operator()(__thread_id __v) const _NOEXCEPT
2010-05-12 03:42:16 +08:00
{
return hash<__libcpp_thread_id>()(__v.__id_);
2010-05-12 03:42:16 +08:00
}
};
template<class _CharT, class _Traits>
_LIBCPP_INLINE_VISIBILITY
basic_ostream<_CharT, _Traits>&
operator<<(basic_ostream<_CharT, _Traits>& __os, __thread_id __id)
{return __os << __id.__id_;}
2010-05-12 03:42:16 +08:00
class _LIBCPP_TYPE_VIS thread
2010-05-12 03:42:16 +08:00
{
__libcpp_thread_t __t_;
2010-05-12 03:42:16 +08:00
thread(const thread&);
thread& operator=(const thread&);
2010-05-12 03:42:16 +08:00
public:
typedef __thread_id id;
typedef __libcpp_thread_t native_handle_type;
2010-05-12 03:42:16 +08:00
_LIBCPP_INLINE_VISIBILITY
thread() _NOEXCEPT : __t_(_LIBCPP_NULL_THREAD) {}
#ifndef _LIBCPP_CXX03_LANG
template <class _Fp, class ..._Args,
2010-05-12 03:42:16 +08:00
class = typename enable_if
<
!is_same<typename __uncvref<_Fp>::type, thread>::value
2010-05-12 03:42:16 +08:00
>::type
>
_LIBCPP_METHOD_TEMPLATE_IMPLICIT_INSTANTIATION_VIS
explicit thread(_Fp&& __f, _Args&&... __args);
#else // _LIBCPP_CXX03_LANG
template <class _Fp>
_LIBCPP_METHOD_TEMPLATE_IMPLICIT_INSTANTIATION_VIS
explicit thread(_Fp __f);
2010-05-12 03:42:16 +08:00
#endif
~thread();
_LIBCPP_INLINE_VISIBILITY
thread(thread&& __t) _NOEXCEPT : __t_(__t.__t_) {
__t.__t_ = _LIBCPP_NULL_THREAD;
}
_LIBCPP_INLINE_VISIBILITY
thread& operator=(thread&& __t) _NOEXCEPT {
if (!__libcpp_thread_isnull(&__t_))
terminate();
__t_ = __t.__t_;
__t.__t_ = _LIBCPP_NULL_THREAD;
return *this;
}
2010-05-12 03:42:16 +08:00
_LIBCPP_INLINE_VISIBILITY
void swap(thread& __t) _NOEXCEPT {_VSTD::swap(__t_, __t.__t_);}
2010-05-12 03:42:16 +08:00
_LIBCPP_INLINE_VISIBILITY
bool joinable() const _NOEXCEPT {return !__libcpp_thread_isnull(&__t_);}
2010-05-12 03:42:16 +08:00
void join();
void detach();
_LIBCPP_INLINE_VISIBILITY
id get_id() const _NOEXCEPT {return __libcpp_thread_get_id(&__t_);}
_LIBCPP_INLINE_VISIBILITY
native_handle_type native_handle() _NOEXCEPT {return __t_;}
2010-05-12 03:42:16 +08:00
static unsigned hardware_concurrency() _NOEXCEPT;
2010-05-12 03:42:16 +08:00
};
#ifndef _LIBCPP_CXX03_LANG
template <class _TSp, class _Fp, class ..._Args, size_t ..._Indices>
inline _LIBCPP_INLINE_VISIBILITY
void
__thread_execute(tuple<_TSp, _Fp, _Args...>& __t, __tuple_indices<_Indices...>)
{
_VSTD::__invoke(_VSTD::move(_VSTD::get<1>(__t)), _VSTD::move(_VSTD::get<_Indices>(__t))...);
}
template <class _Fp>
_LIBCPP_INLINE_VISIBILITY
void* __thread_proxy(void* __vp)
2010-05-12 03:42:16 +08:00
{
// _Fp = tuple< unique_ptr<__thread_struct>, Functor, Args...>
unique_ptr<_Fp> __p(static_cast<_Fp*>(__vp));
__thread_local_data().set_pointer(_VSTD::get<0>(*__p.get()).release());
typedef typename __make_tuple_indices<tuple_size<_Fp>::value, 2>::type _Index;
_VSTD::__thread_execute(*__p.get(), _Index());
2010-05-12 03:42:16 +08:00
return nullptr;
}
template <class _Fp, class ..._Args,
2010-05-12 03:42:16 +08:00
class
>
thread::thread(_Fp&& __f, _Args&&... __args)
2010-05-12 03:42:16 +08:00
{
typedef unique_ptr<__thread_struct> _TSPtr;
_TSPtr __tsp(new __thread_struct);
typedef tuple<_TSPtr, typename decay<_Fp>::type, typename decay<_Args>::type...> _Gp;
unique_ptr<_Gp> __p(
new _Gp(_VSTD::move(__tsp),
_VSTD::__decay_copy(_VSTD::forward<_Fp>(__f)),
_VSTD::__decay_copy(_VSTD::forward<_Args>(__args))...));
int __ec = _VSTD::__libcpp_thread_create(&__t_, &__thread_proxy<_Gp>, __p.get());
2010-05-12 03:42:16 +08:00
if (__ec == 0)
__p.release();
else
__throw_system_error(__ec, "thread constructor failed");
}
#else // _LIBCPP_CXX03_LANG
2010-05-12 03:42:16 +08:00
template <class _Fp>
struct __thread_invoke_pair {
// This type is used to pass memory for thread local storage and a functor
// to a newly created thread because std::pair doesn't work with
// std::unique_ptr in C++03.
__thread_invoke_pair(_Fp& __f) : __tsp_(new __thread_struct), __fn_(__f) {}
unique_ptr<__thread_struct> __tsp_;
_Fp __fn_;
};
template <class _Fp>
void* __thread_proxy_cxx03(void* __vp)
{
unique_ptr<_Fp> __p(static_cast<_Fp*>(__vp));
Fix PR30202 - notify_all_at_thread_exit seg faults if run from a raw pthread context. 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". Reviewers: mclow.lists, bcraig, EricWF Subscribers: cfe-commits Differential Revision: https://reviews.llvm.org/D24159 llvm-svn: 280588
2016-09-03 16:07:40 +08:00
__thread_local_data().set_pointer(__p->__tsp_.release());
(__p->__fn_)();
return nullptr;
}
template <class _Fp>
thread::thread(_Fp __f)
2010-05-12 03:42:16 +08:00
{
typedef __thread_invoke_pair<_Fp> _InvokePair;
typedef unique_ptr<_InvokePair> _PairPtr;
_PairPtr __pp(new _InvokePair(__f));
int __ec = _VSTD::__libcpp_thread_create(&__t_, &__thread_proxy_cxx03<_InvokePair>, __pp.get());
2010-05-12 03:42:16 +08:00
if (__ec == 0)
__pp.release();
2010-05-12 03:42:16 +08:00
else
__throw_system_error(__ec, "thread constructor failed");
}
#endif // _LIBCPP_CXX03_LANG
2010-05-12 03:42:16 +08:00
inline _LIBCPP_INLINE_VISIBILITY
void swap(thread& __x, thread& __y) _NOEXCEPT {__x.swap(__y);}
2010-05-12 03:42:16 +08:00
namespace this_thread
{
_LIBCPP_FUNC_VIS void sleep_for(const chrono::nanoseconds& __ns);
2010-05-12 03:42:16 +08:00
template <class _Rep, class _Period>
void
sleep_for(const chrono::duration<_Rep, _Period>& __d)
{
if (__d > chrono::duration<_Rep, _Period>::zero())
{
#if defined(_LIBCPP_COMPILER_GCC) && (__powerpc__ || __POWERPC__)
// GCC's long double const folding is incomplete for IBM128 long doubles.
_LIBCPP_CONSTEXPR chrono::duration<long double> _Max = chrono::duration<long double>(ULLONG_MAX/1000000000ULL) ;
#else
_LIBCPP_CONSTEXPR chrono::duration<long double> _Max = chrono::nanoseconds::max();
#endif
chrono::nanoseconds __ns;
if (__d < _Max)
{
__ns = chrono::duration_cast<chrono::nanoseconds>(__d);
if (__ns < __d)
++__ns;
}
else
__ns = chrono::nanoseconds::max();
this_thread::sleep_for(__ns);
}
2010-05-12 03:42:16 +08:00
}
template <class _Clock, class _Duration>
void
sleep_until(const chrono::time_point<_Clock, _Duration>& __t)
{
mutex __mut;
condition_variable __cv;
unique_lock<mutex> __lk(__mut);
while (_Clock::now() < __t)
__cv.wait_until(__lk, __t);
}
template <class _Duration>
inline _LIBCPP_INLINE_VISIBILITY
2010-05-12 03:42:16 +08:00
void
sleep_until(const chrono::time_point<chrono::steady_clock, _Duration>& __t)
2010-05-12 03:42:16 +08:00
{
this_thread::sleep_for(__t - chrono::steady_clock::now());
2010-05-12 03:42:16 +08:00
}
inline _LIBCPP_INLINE_VISIBILITY
void yield() _NOEXCEPT {__libcpp_thread_yield();}
2010-05-12 03:42:16 +08:00
} // this_thread
_LIBCPP_END_NAMESPACE_STD
#endif // !_LIBCPP_HAS_NO_THREADS
_LIBCPP_POP_MACROS
2010-05-12 03:42:16 +08:00
#endif // _LIBCPP_THREAD