llvm-project/libcxx/include/thread

482 lines
13 KiB
Plaintext
Raw Normal View History

2010-05-12 03:42:16 +08:00
// -*- C++ -*-
//===--------------------------- thread -----------------------------------===//
//
// The LLVM Compiler Infrastructure
2010-05-12 03:42:16 +08:00
//
2010-11-17 06:09:02 +08:00
// This file is dual licensed under the MIT and the University of Illinois Open
// Source Licenses. See LICENSE.TXT for details.
2010-05-12 03:42:16 +08:00
//
//===----------------------------------------------------------------------===//
#ifndef _LIBCPP_THREAD
#define _LIBCPP_THREAD
/*
thread synopsis
2010-08-22 05:01:59 +08:00
#define __STDCPP_THREADS__ __cplusplus
2010-05-12 03:42:16 +08:00
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_HAS_NO_VARIADICS
#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
2010-08-22 05:01:59 +08:00
#define __STDCPP_THREADS__ __cplusplus
2010-05-12 03:42:16 +08:00
#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&);
static void __at_thread_exit(void*);
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
__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()
{
[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
int __ec = __libcpp_tls_create(
&__key_,
&__thread_specific_ptr::__at_thread_exit);
2011-10-18 04:08:59 +08:00
if (__ec)
__throw_system_error(__ec,
2011-10-18 04:08:59 +08:00
"__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
}
class _LIBCPP_TYPE_VIS thread;
class _LIBCPP_TYPE_VIS __thread_id;
2010-05-12 03:42:16 +08:00
namespace this_thread
{
_LIBCPP_INLINE_VISIBILITY __thread_id get_id() _NOEXCEPT;
2010-05-12 03:42:16 +08:00
} // this_thread
template<> struct hash<__thread_id>;
class _LIBCPP_TYPE_VIS_ONLY __thread_id
2010-05-12 03:42:16 +08:00
{
// FIXME: pthread_t is a pointer on Darwin but a long on Linux.
// NULL is the no-thread value on Darwin. Someone needs to check
// on other platforms. We assume 0 works everywhere for now.
__libcpp_thread_id __id_;
2010-05-12 03:42:16 +08:00
public:
_LIBCPP_INLINE_VISIBILITY
__thread_id() _NOEXCEPT : __id_(0) {}
2010-05-12 03:42:16 +08:00
friend _LIBCPP_INLINE_VISIBILITY
bool operator==(__thread_id __x, __thread_id __y) _NOEXCEPT
{return __libcpp_thread_id_equal(__x.__id_, __y.__id_);}
friend _LIBCPP_INLINE_VISIBILITY
bool operator!=(__thread_id __x, __thread_id __y) _NOEXCEPT
2010-05-12 03:42:16 +08:00
{return !(__x == __y);}
friend _LIBCPP_INLINE_VISIBILITY
bool operator< (__thread_id __x, __thread_id __y) _NOEXCEPT
{return __libcpp_thread_id_less(__x.__id_, __y.__id_);}
friend _LIBCPP_INLINE_VISIBILITY
bool operator<=(__thread_id __x, __thread_id __y) _NOEXCEPT
2010-05-12 03:42:16 +08:00
{return !(__y < __x);}
friend _LIBCPP_INLINE_VISIBILITY
bool operator> (__thread_id __x, __thread_id __y) _NOEXCEPT
2010-05-12 03:42:16 +08:00
{return __y < __x ;}
friend _LIBCPP_INLINE_VISIBILITY
bool operator>=(__thread_id __x, __thread_id __y) _NOEXCEPT
2010-05-12 03:42:16 +08:00
{return !(__x < __y);}
template<class _CharT, class _Traits>
friend
_LIBCPP_INLINE_VISIBILITY
2010-05-12 03:42:16 +08:00
basic_ostream<_CharT, _Traits>&
operator<<(basic_ostream<_CharT, _Traits>& __os, __thread_id __id)
{return __os << __id.__id_;}
private:
_LIBCPP_INLINE_VISIBILITY
__thread_id(__libcpp_thread_id __id) : __id_(__id) {}
2010-05-12 03:42:16 +08:00
friend __thread_id this_thread::get_id() _NOEXCEPT;
friend class _LIBCPP_TYPE_VIS thread;
friend struct _LIBCPP_TYPE_VIS_ONLY hash<__thread_id>;
2010-05-12 03:42:16 +08:00
};
template<>
struct _LIBCPP_TYPE_VIS_ONLY hash<__thread_id>
2010-05-12 03:42:16 +08:00
: public unary_function<__thread_id, size_t>
{
_LIBCPP_INLINE_VISIBILITY
2010-05-12 03:42:16 +08:00
size_t operator()(__thread_id __v) const
{
return hash<__libcpp_thread_id>()(__v.__id_);
2010-05-12 03:42:16 +08:00
}
};
namespace this_thread
{
inline _LIBCPP_INLINE_VISIBILITY
2010-05-12 03:42:16 +08:00
__thread_id
get_id() _NOEXCEPT
2010-05-12 03:42:16 +08:00
{
return __libcpp_thread_get_current_id();
2010-05-12 03:42:16 +08:00
}
} // this_thread
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_(0) {}
2010-05-12 03:42:16 +08:00
#ifndef _LIBCPP_HAS_NO_VARIADICS
template <class _Fp, class ..._Args,
2010-05-12 03:42:16 +08:00
class = typename enable_if
<
!is_same<typename decay<_Fp>::type, thread>::value
2010-05-12 03:42:16 +08:00
>::type
>
explicit thread(_Fp&& __f, _Args&&... __args);
#else // _LIBCPP_HAS_NO_VARIADICS
template <class _Fp> explicit thread(_Fp __f);
2010-05-12 03:42:16 +08:00
#endif
~thread();
#ifndef _LIBCPP_HAS_NO_RVALUE_REFERENCES
_LIBCPP_INLINE_VISIBILITY
thread(thread&& __t) _NOEXCEPT : __t_(__t.__t_) {__t.__t_ = 0;}
_LIBCPP_INLINE_VISIBILITY
thread& operator=(thread&& __t) _NOEXCEPT;
#endif // _LIBCPP_HAS_NO_RVALUE_REFERENCES
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 __t_ != 0;}
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_HAS_NO_VARIADICS
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...>)
{
__invoke(_VSTD::move(_VSTD::get<1>(__t)), _VSTD::move(_VSTD::get<_Indices>(__t))...);
}
template <class _Fp>
void* __thread_proxy(void* __vp)
2010-05-12 03:42:16 +08:00
{
// _Fp = std::tuple< unique_ptr<__thread_struct>, Functor, Args...>
std::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(_VSTD::get<0>(*__p).release());
typedef typename __make_tuple_indices<tuple_size<_Fp>::value, 2>::type _Index;
__thread_execute(*__p, _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;
_VSTD::unique_ptr<_Gp> __p(
new _Gp(std::move(__tsp),
__decay_copy(_VSTD::forward<_Fp>(__f)),
__decay_copy(_VSTD::forward<_Args>(__args))...));
int __ec = __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_HAS_NO_VARIADICS
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)
{
std::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 std::unique_ptr<_InvokePair> _PairPtr;
_PairPtr __pp(new _InvokePair(__f));
int __ec = __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_HAS_NO_VARIADICS
2010-05-12 03:42:16 +08:00
#ifndef _LIBCPP_HAS_NO_RVALUE_REFERENCES
2010-05-12 03:42:16 +08:00
inline
2010-05-12 03:42:16 +08:00
thread&
thread::operator=(thread&& __t) _NOEXCEPT
2010-05-12 03:42:16 +08:00
{
2010-06-03 02:20:39 +08:00
if (__t_ != 0)
2010-05-12 03:42:16 +08:00
terminate();
__t_ = __t.__t_;
2010-06-03 02:20:39 +08:00
__t.__t_ = 0;
2010-05-12 03:42:16 +08:00
return *this;
}
#endif // _LIBCPP_HAS_NO_RVALUE_REFERENCES
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)
{
using namespace chrono;
if (__d > duration<_Rep, _Period>::zero())
{
_LIBCPP_CONSTEXPR duration<long double> _Max = nanoseconds::max();
nanoseconds __ns;
if (__d < _Max)
{
__ns = duration_cast<nanoseconds>(__d);
if (__ns < __d)
++__ns;
}
else
__ns = nanoseconds::max();
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)
{
using namespace chrono;
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
{
using namespace chrono;
sleep_for(__t - 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
2010-05-12 03:42:16 +08:00
#endif // _LIBCPP_THREAD