2016-05-06 22:06:29 +08:00
|
|
|
// -*- C++ -*-
|
|
|
|
//===----------------------------------------------------------------------===//
|
|
|
|
//
|
2019-01-19 18:56:40 +08:00
|
|
|
// 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
|
2016-05-06 22:06:29 +08:00
|
|
|
//
|
|
|
|
//===----------------------------------------------------------------------===//
|
|
|
|
|
|
|
|
#ifndef _LIBCPP_THREADING_SUPPORT
|
|
|
|
#define _LIBCPP_THREADING_SUPPORT
|
|
|
|
|
|
|
|
#include <__config>
|
2017-02-09 17:31:41 +08:00
|
|
|
#include <chrono>
|
2019-08-15 00:21:27 +08:00
|
|
|
#include <iosfwd>
|
2017-02-09 17:31:41 +08:00
|
|
|
#include <errno.h>
|
2016-05-06 22:06:29 +08:00
|
|
|
|
|
|
|
#ifndef _LIBCPP_HAS_NO_PRAGMA_SYSTEM_HEADER
|
|
|
|
#pragma GCC system_header
|
|
|
|
#endif
|
|
|
|
|
2017-01-07 04:05:40 +08:00
|
|
|
#if defined(_LIBCPP_HAS_THREAD_API_EXTERNAL)
|
|
|
|
# include <__external_threading>
|
|
|
|
#elif !defined(_LIBCPP_HAS_NO_THREADS)
|
2017-01-03 10:00:31 +08:00
|
|
|
|
2017-01-07 04:05:40 +08:00
|
|
|
#if defined(_LIBCPP_HAS_THREAD_API_PTHREAD)
|
|
|
|
# include <pthread.h>
|
|
|
|
# include <sched.h>
|
2020-02-18 22:58:34 +08:00
|
|
|
# ifdef __APPLE__
|
|
|
|
# define _LIBCPP_NO_NATIVE_SEMAPHORES
|
|
|
|
# endif
|
2020-02-27 08:49:37 +08:00
|
|
|
# ifndef _LIBCPP_NO_NATIVE_SEMAPHORES
|
|
|
|
# include <semaphore.h>
|
|
|
|
# endif
|
2019-12-05 02:38:22 +08:00
|
|
|
#elif defined(_LIBCPP_HAS_THREAD_API_C11)
|
|
|
|
# include <threads.h>
|
2017-01-03 10:00:31 +08:00
|
|
|
#endif
|
2016-05-06 22:06:29 +08:00
|
|
|
|
2018-02-22 05:36:18 +08:00
|
|
|
#if defined(_LIBCPP_HAS_THREAD_LIBRARY_EXTERNAL) || \
|
|
|
|
defined(_LIBCPP_BUILDING_THREAD_LIBRARY_EXTERNAL) || \
|
|
|
|
defined(_LIBCPP_HAS_THREAD_API_WIN32)
|
|
|
|
#define _LIBCPP_THREAD_ABI_VISIBILITY _LIBCPP_FUNC_VIS
|
|
|
|
#else
|
|
|
|
#define _LIBCPP_THREAD_ABI_VISIBILITY inline _LIBCPP_INLINE_VISIBILITY
|
|
|
|
#endif
|
|
|
|
|
Disable thread safety analysis for some functions in __thread_support
Many thread-related libc++ test cases fail on FreeBSD, due to the
following -Werror warnings:
In file included from test/std/thread/thread.threads/thread.thread.this/sleep_until.pass.cpp:17:
In file included from include/thread:97:
In file included from include/__mutex_base:17:
include/__threading_support:222:1: error: mutex '__m' is still held at the end of function [-Werror,-Wthread-safety-analysis]
}
^
include/__threading_support:221:10: note: mutex acquired here
return pthread_mutex_lock(__m);
^
include/__threading_support:231:10: error: releasing mutex '__m' that was not held [-Werror,-Wthread-safety-analysis]
return pthread_mutex_unlock(__m);
^
include/__threading_support:242:1: error: mutex '__m' is still held at the end of function [-Werror,-Wthread-safety-analysis]
}
^
include/__threading_support:241:10: note: mutex acquired here
return pthread_mutex_lock(__m);
^
include/__threading_support:251:10: error: releasing mutex '__m' that was not held [-Werror,-Wthread-safety-analysis]
return pthread_mutex_unlock(__m);
^
include/__threading_support:272:10: error: calling function 'pthread_cond_wait' requires holding mutex '__m' exclusively [-Werror,-Wthread-safety-analysis]
return pthread_cond_wait(__cv, __m);
^
include/__threading_support:278:10: error: calling function 'pthread_cond_timedwait' requires holding mutex '__m' exclusively [-Werror,-Wthread-safety-analysis]
return pthread_cond_timedwait(__cv, __m, __ts);
^
6 errors generated.
This is because on FreeBSD, the pthread functions have lock annotations.
Since the functions in __thread_support are internal to libc++ only, add
no_thread_safety_analysis attributes to suppress these warnings.
Reviewers: mclow.lists, EricWF, delesley, aaron.ballman
Reviewed By: aaron.ballman
Subscribers: ed, aaron.ballman, joerg, emaste, cfe-commits
Differential Revision: https://reviews.llvm.org/D28520
llvm-svn: 293197
2017-01-27 02:37:18 +08:00
|
|
|
#if defined(__FreeBSD__) && defined(__clang__) && __has_attribute(no_thread_safety_analysis)
|
|
|
|
#define _LIBCPP_NO_THREAD_SAFETY_ANALYSIS __attribute__((no_thread_safety_analysis))
|
|
|
|
#else
|
|
|
|
#define _LIBCPP_NO_THREAD_SAFETY_ANALYSIS
|
|
|
|
#endif
|
|
|
|
|
2019-08-21 00:16:23 +08:00
|
|
|
typedef ::timespec __libcpp_timespec_t;
|
|
|
|
#endif // !defined(_LIBCPP_HAS_NO_THREADS)
|
|
|
|
|
|
|
|
_LIBCPP_PUSH_MACROS
|
|
|
|
#include <__undef_macros>
|
|
|
|
|
[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_BEGIN_NAMESPACE_STD
|
2016-05-06 22:06:29 +08:00
|
|
|
|
2019-08-21 00:16:23 +08:00
|
|
|
#if !defined(_LIBCPP_HAS_NO_THREADS)
|
|
|
|
|
2018-02-22 05:36:18 +08:00
|
|
|
#if defined(_LIBCPP_HAS_THREAD_API_PTHREAD)
|
2016-05-06 22:06:29 +08:00
|
|
|
// Mutex
|
|
|
|
typedef pthread_mutex_t __libcpp_mutex_t;
|
[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
|
|
|
#define _LIBCPP_MUTEX_INITIALIZER PTHREAD_MUTEX_INITIALIZER
|
|
|
|
|
2017-01-06 01:54:45 +08:00
|
|
|
typedef pthread_mutex_t __libcpp_recursive_mutex_t;
|
|
|
|
|
2017-01-03 10:00:31 +08:00
|
|
|
// Condition Variable
|
|
|
|
typedef pthread_cond_t __libcpp_condvar_t;
|
|
|
|
#define _LIBCPP_CONDVAR_INITIALIZER PTHREAD_COND_INITIALIZER
|
|
|
|
|
2020-02-27 08:49:37 +08:00
|
|
|
#ifndef _LIBCPP_NO_NATIVE_SEMAPHORES
|
2020-02-18 22:58:34 +08:00
|
|
|
// Semaphore
|
|
|
|
typedef sem_t __libcpp_semaphore_t;
|
2020-02-27 08:49:37 +08:00
|
|
|
# define _LIBCPP_SEMAPHORE_MAX SEM_VALUE_MAX
|
|
|
|
#endif
|
2020-02-18 22:58:34 +08:00
|
|
|
|
2017-01-03 20:59:50 +08:00
|
|
|
// Execute once
|
|
|
|
typedef pthread_once_t __libcpp_exec_once_flag;
|
|
|
|
#define _LIBCPP_EXEC_ONCE_INITIALIZER PTHREAD_ONCE_INIT
|
|
|
|
|
|
|
|
// Thread id
|
2017-01-03 10:00:31 +08:00
|
|
|
typedef pthread_t __libcpp_thread_id;
|
|
|
|
|
|
|
|
// Thread
|
2017-01-16 20:19:54 +08:00
|
|
|
#define _LIBCPP_NULL_THREAD 0U
|
|
|
|
|
2017-01-03 10:00:31 +08:00
|
|
|
typedef pthread_t __libcpp_thread_t;
|
|
|
|
|
2018-09-17 15:40:42 +08:00
|
|
|
// Thread Local Storage
|
2017-01-03 10:00:31 +08:00
|
|
|
typedef pthread_key_t __libcpp_tls_key;
|
2017-01-07 11:07:45 +08:00
|
|
|
|
2019-12-05 02:38:22 +08:00
|
|
|
#define _LIBCPP_TLS_DESTRUCTOR_CC
|
|
|
|
#elif defined(_LIBCPP_HAS_THREAD_API_C11)
|
|
|
|
// Mutex
|
|
|
|
typedef mtx_t __libcpp_mutex_t;
|
|
|
|
// mtx_t is a struct so using {} for initialization is valid.
|
|
|
|
#define _LIBCPP_MUTEX_INITIALIZER {}
|
|
|
|
|
|
|
|
typedef mtx_t __libcpp_recursive_mutex_t;
|
|
|
|
|
|
|
|
// Condition Variable
|
|
|
|
typedef cnd_t __libcpp_condvar_t;
|
|
|
|
// cnd_t is a struct so using {} for initialization is valid.
|
|
|
|
#define _LIBCPP_CONDVAR_INITIALIZER {}
|
|
|
|
|
|
|
|
// Execute once
|
|
|
|
typedef once_flag __libcpp_exec_once_flag;
|
|
|
|
#define _LIBCPP_EXEC_ONCE_INITIALIZER ONCE_FLAG_INIT
|
|
|
|
|
|
|
|
// Thread id
|
|
|
|
typedef thrd_t __libcpp_thread_id;
|
|
|
|
|
|
|
|
// Thread
|
|
|
|
#define _LIBCPP_NULL_THREAD 0U
|
|
|
|
|
|
|
|
typedef thrd_t __libcpp_thread_t;
|
|
|
|
|
|
|
|
// Thread Local Storage
|
|
|
|
typedef tss_t __libcpp_tls_key;
|
|
|
|
|
2017-01-07 11:07:45 +08:00
|
|
|
#define _LIBCPP_TLS_DESTRUCTOR_CC
|
2019-08-21 23:38:24 +08:00
|
|
|
#elif !defined(_LIBCPP_HAS_THREAD_API_EXTERNAL)
|
2017-01-07 11:07:45 +08:00
|
|
|
// Mutex
|
2018-01-23 09:59:43 +08:00
|
|
|
typedef void* __libcpp_mutex_t;
|
|
|
|
#define _LIBCPP_MUTEX_INITIALIZER 0
|
2017-01-07 11:07:45 +08:00
|
|
|
|
2018-01-23 09:59:43 +08:00
|
|
|
#if defined(_M_IX86) || defined(__i386__) || defined(_M_ARM) || defined(__arm__)
|
|
|
|
typedef void* __libcpp_recursive_mutex_t[6];
|
|
|
|
#elif defined(_M_AMD64) || defined(__x86_64__) || defined(_M_ARM64) || defined(__aarch64__)
|
|
|
|
typedef void* __libcpp_recursive_mutex_t[5];
|
|
|
|
#else
|
|
|
|
# error Unsupported architecture
|
|
|
|
#endif
|
2017-01-07 11:07:45 +08:00
|
|
|
|
|
|
|
// Condition Variable
|
2018-01-23 09:59:43 +08:00
|
|
|
typedef void* __libcpp_condvar_t;
|
|
|
|
#define _LIBCPP_CONDVAR_INITIALIZER 0
|
2017-01-07 11:07:45 +08:00
|
|
|
|
2020-02-18 22:58:34 +08:00
|
|
|
// Semaphore
|
|
|
|
typedef void* __libcpp_semaphore_t;
|
|
|
|
|
2017-01-07 11:07:45 +08:00
|
|
|
// Execute Once
|
2018-01-23 09:59:43 +08:00
|
|
|
typedef void* __libcpp_exec_once_flag;
|
|
|
|
#define _LIBCPP_EXEC_ONCE_INITIALIZER 0
|
2017-01-07 11:07:45 +08:00
|
|
|
|
|
|
|
// Thread ID
|
2018-01-23 09:59:43 +08:00
|
|
|
typedef long __libcpp_thread_id;
|
2017-01-07 11:07:45 +08:00
|
|
|
|
|
|
|
// Thread
|
2017-01-16 20:19:54 +08:00
|
|
|
#define _LIBCPP_NULL_THREAD 0U
|
|
|
|
|
2018-01-23 09:59:43 +08:00
|
|
|
typedef void* __libcpp_thread_t;
|
2017-01-07 11:07:45 +08:00
|
|
|
|
|
|
|
// Thread Local Storage
|
2018-01-23 09:59:43 +08:00
|
|
|
typedef long __libcpp_tls_key;
|
2017-01-07 11:07:45 +08:00
|
|
|
|
2018-01-23 09:59:43 +08:00
|
|
|
#define _LIBCPP_TLS_DESTRUCTOR_CC __stdcall
|
2019-08-21 23:38:24 +08:00
|
|
|
#endif // !defined(_LIBCPP_HAS_THREAD_API_PTHREAD) && !defined(_LIBCPP_HAS_THREAD_API_EXTERNAL)
|
2017-01-03 10:00:31 +08:00
|
|
|
|
2019-08-21 23:38:24 +08:00
|
|
|
#if !defined(_LIBCPP_HAS_THREAD_API_EXTERNAL)
|
2017-01-03 10:00:31 +08:00
|
|
|
// Mutex
|
[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_THREAD_ABI_VISIBILITY
|
2017-01-06 01:54:45 +08:00
|
|
|
int __libcpp_recursive_mutex_init(__libcpp_recursive_mutex_t *__m);
|
|
|
|
|
Disable thread safety analysis for some functions in __thread_support
Many thread-related libc++ test cases fail on FreeBSD, due to the
following -Werror warnings:
In file included from test/std/thread/thread.threads/thread.thread.this/sleep_until.pass.cpp:17:
In file included from include/thread:97:
In file included from include/__mutex_base:17:
include/__threading_support:222:1: error: mutex '__m' is still held at the end of function [-Werror,-Wthread-safety-analysis]
}
^
include/__threading_support:221:10: note: mutex acquired here
return pthread_mutex_lock(__m);
^
include/__threading_support:231:10: error: releasing mutex '__m' that was not held [-Werror,-Wthread-safety-analysis]
return pthread_mutex_unlock(__m);
^
include/__threading_support:242:1: error: mutex '__m' is still held at the end of function [-Werror,-Wthread-safety-analysis]
}
^
include/__threading_support:241:10: note: mutex acquired here
return pthread_mutex_lock(__m);
^
include/__threading_support:251:10: error: releasing mutex '__m' that was not held [-Werror,-Wthread-safety-analysis]
return pthread_mutex_unlock(__m);
^
include/__threading_support:272:10: error: calling function 'pthread_cond_wait' requires holding mutex '__m' exclusively [-Werror,-Wthread-safety-analysis]
return pthread_cond_wait(__cv, __m);
^
include/__threading_support:278:10: error: calling function 'pthread_cond_timedwait' requires holding mutex '__m' exclusively [-Werror,-Wthread-safety-analysis]
return pthread_cond_timedwait(__cv, __m, __ts);
^
6 errors generated.
This is because on FreeBSD, the pthread functions have lock annotations.
Since the functions in __thread_support are internal to libc++ only, add
no_thread_safety_analysis attributes to suppress these warnings.
Reviewers: mclow.lists, EricWF, delesley, aaron.ballman
Reviewed By: aaron.ballman
Subscribers: ed, aaron.ballman, joerg, emaste, cfe-commits
Differential Revision: https://reviews.llvm.org/D28520
llvm-svn: 293197
2017-01-27 02:37:18 +08:00
|
|
|
_LIBCPP_THREAD_ABI_VISIBILITY _LIBCPP_NO_THREAD_SAFETY_ANALYSIS
|
2017-01-06 01:54:45 +08:00
|
|
|
int __libcpp_recursive_mutex_lock(__libcpp_recursive_mutex_t *__m);
|
|
|
|
|
Disable thread safety analysis for some functions in __thread_support
Many thread-related libc++ test cases fail on FreeBSD, due to the
following -Werror warnings:
In file included from test/std/thread/thread.threads/thread.thread.this/sleep_until.pass.cpp:17:
In file included from include/thread:97:
In file included from include/__mutex_base:17:
include/__threading_support:222:1: error: mutex '__m' is still held at the end of function [-Werror,-Wthread-safety-analysis]
}
^
include/__threading_support:221:10: note: mutex acquired here
return pthread_mutex_lock(__m);
^
include/__threading_support:231:10: error: releasing mutex '__m' that was not held [-Werror,-Wthread-safety-analysis]
return pthread_mutex_unlock(__m);
^
include/__threading_support:242:1: error: mutex '__m' is still held at the end of function [-Werror,-Wthread-safety-analysis]
}
^
include/__threading_support:241:10: note: mutex acquired here
return pthread_mutex_lock(__m);
^
include/__threading_support:251:10: error: releasing mutex '__m' that was not held [-Werror,-Wthread-safety-analysis]
return pthread_mutex_unlock(__m);
^
include/__threading_support:272:10: error: calling function 'pthread_cond_wait' requires holding mutex '__m' exclusively [-Werror,-Wthread-safety-analysis]
return pthread_cond_wait(__cv, __m);
^
include/__threading_support:278:10: error: calling function 'pthread_cond_timedwait' requires holding mutex '__m' exclusively [-Werror,-Wthread-safety-analysis]
return pthread_cond_timedwait(__cv, __m, __ts);
^
6 errors generated.
This is because on FreeBSD, the pthread functions have lock annotations.
Since the functions in __thread_support are internal to libc++ only, add
no_thread_safety_analysis attributes to suppress these warnings.
Reviewers: mclow.lists, EricWF, delesley, aaron.ballman
Reviewed By: aaron.ballman
Subscribers: ed, aaron.ballman, joerg, emaste, cfe-commits
Differential Revision: https://reviews.llvm.org/D28520
llvm-svn: 293197
2017-01-27 02:37:18 +08:00
|
|
|
_LIBCPP_THREAD_ABI_VISIBILITY _LIBCPP_NO_THREAD_SAFETY_ANALYSIS
|
2017-01-14 18:27:12 +08:00
|
|
|
bool __libcpp_recursive_mutex_trylock(__libcpp_recursive_mutex_t *__m);
|
2017-01-06 01:54:45 +08:00
|
|
|
|
Disable thread safety analysis for some functions in __thread_support
Many thread-related libc++ test cases fail on FreeBSD, due to the
following -Werror warnings:
In file included from test/std/thread/thread.threads/thread.thread.this/sleep_until.pass.cpp:17:
In file included from include/thread:97:
In file included from include/__mutex_base:17:
include/__threading_support:222:1: error: mutex '__m' is still held at the end of function [-Werror,-Wthread-safety-analysis]
}
^
include/__threading_support:221:10: note: mutex acquired here
return pthread_mutex_lock(__m);
^
include/__threading_support:231:10: error: releasing mutex '__m' that was not held [-Werror,-Wthread-safety-analysis]
return pthread_mutex_unlock(__m);
^
include/__threading_support:242:1: error: mutex '__m' is still held at the end of function [-Werror,-Wthread-safety-analysis]
}
^
include/__threading_support:241:10: note: mutex acquired here
return pthread_mutex_lock(__m);
^
include/__threading_support:251:10: error: releasing mutex '__m' that was not held [-Werror,-Wthread-safety-analysis]
return pthread_mutex_unlock(__m);
^
include/__threading_support:272:10: error: calling function 'pthread_cond_wait' requires holding mutex '__m' exclusively [-Werror,-Wthread-safety-analysis]
return pthread_cond_wait(__cv, __m);
^
include/__threading_support:278:10: error: calling function 'pthread_cond_timedwait' requires holding mutex '__m' exclusively [-Werror,-Wthread-safety-analysis]
return pthread_cond_timedwait(__cv, __m, __ts);
^
6 errors generated.
This is because on FreeBSD, the pthread functions have lock annotations.
Since the functions in __thread_support are internal to libc++ only, add
no_thread_safety_analysis attributes to suppress these warnings.
Reviewers: mclow.lists, EricWF, delesley, aaron.ballman
Reviewed By: aaron.ballman
Subscribers: ed, aaron.ballman, joerg, emaste, cfe-commits
Differential Revision: https://reviews.llvm.org/D28520
llvm-svn: 293197
2017-01-27 02:37:18 +08:00
|
|
|
_LIBCPP_THREAD_ABI_VISIBILITY _LIBCPP_NO_THREAD_SAFETY_ANALYSIS
|
2017-01-06 01:54:45 +08:00
|
|
|
int __libcpp_recursive_mutex_unlock(__libcpp_recursive_mutex_t *__m);
|
|
|
|
|
|
|
|
_LIBCPP_THREAD_ABI_VISIBILITY
|
|
|
|
int __libcpp_recursive_mutex_destroy(__libcpp_recursive_mutex_t *__m);
|
2017-01-03 10:00:31 +08:00
|
|
|
|
Disable thread safety analysis for some functions in __thread_support
Many thread-related libc++ test cases fail on FreeBSD, due to the
following -Werror warnings:
In file included from test/std/thread/thread.threads/thread.thread.this/sleep_until.pass.cpp:17:
In file included from include/thread:97:
In file included from include/__mutex_base:17:
include/__threading_support:222:1: error: mutex '__m' is still held at the end of function [-Werror,-Wthread-safety-analysis]
}
^
include/__threading_support:221:10: note: mutex acquired here
return pthread_mutex_lock(__m);
^
include/__threading_support:231:10: error: releasing mutex '__m' that was not held [-Werror,-Wthread-safety-analysis]
return pthread_mutex_unlock(__m);
^
include/__threading_support:242:1: error: mutex '__m' is still held at the end of function [-Werror,-Wthread-safety-analysis]
}
^
include/__threading_support:241:10: note: mutex acquired here
return pthread_mutex_lock(__m);
^
include/__threading_support:251:10: error: releasing mutex '__m' that was not held [-Werror,-Wthread-safety-analysis]
return pthread_mutex_unlock(__m);
^
include/__threading_support:272:10: error: calling function 'pthread_cond_wait' requires holding mutex '__m' exclusively [-Werror,-Wthread-safety-analysis]
return pthread_cond_wait(__cv, __m);
^
include/__threading_support:278:10: error: calling function 'pthread_cond_timedwait' requires holding mutex '__m' exclusively [-Werror,-Wthread-safety-analysis]
return pthread_cond_timedwait(__cv, __m, __ts);
^
6 errors generated.
This is because on FreeBSD, the pthread functions have lock annotations.
Since the functions in __thread_support are internal to libc++ only, add
no_thread_safety_analysis attributes to suppress these warnings.
Reviewers: mclow.lists, EricWF, delesley, aaron.ballman
Reviewed By: aaron.ballman
Subscribers: ed, aaron.ballman, joerg, emaste, cfe-commits
Differential Revision: https://reviews.llvm.org/D28520
llvm-svn: 293197
2017-01-27 02:37:18 +08:00
|
|
|
_LIBCPP_THREAD_ABI_VISIBILITY _LIBCPP_NO_THREAD_SAFETY_ANALYSIS
|
2017-01-03 10:00:31 +08:00
|
|
|
int __libcpp_mutex_lock(__libcpp_mutex_t *__m);
|
|
|
|
|
Disable thread safety analysis for some functions in __thread_support
Many thread-related libc++ test cases fail on FreeBSD, due to the
following -Werror warnings:
In file included from test/std/thread/thread.threads/thread.thread.this/sleep_until.pass.cpp:17:
In file included from include/thread:97:
In file included from include/__mutex_base:17:
include/__threading_support:222:1: error: mutex '__m' is still held at the end of function [-Werror,-Wthread-safety-analysis]
}
^
include/__threading_support:221:10: note: mutex acquired here
return pthread_mutex_lock(__m);
^
include/__threading_support:231:10: error: releasing mutex '__m' that was not held [-Werror,-Wthread-safety-analysis]
return pthread_mutex_unlock(__m);
^
include/__threading_support:242:1: error: mutex '__m' is still held at the end of function [-Werror,-Wthread-safety-analysis]
}
^
include/__threading_support:241:10: note: mutex acquired here
return pthread_mutex_lock(__m);
^
include/__threading_support:251:10: error: releasing mutex '__m' that was not held [-Werror,-Wthread-safety-analysis]
return pthread_mutex_unlock(__m);
^
include/__threading_support:272:10: error: calling function 'pthread_cond_wait' requires holding mutex '__m' exclusively [-Werror,-Wthread-safety-analysis]
return pthread_cond_wait(__cv, __m);
^
include/__threading_support:278:10: error: calling function 'pthread_cond_timedwait' requires holding mutex '__m' exclusively [-Werror,-Wthread-safety-analysis]
return pthread_cond_timedwait(__cv, __m, __ts);
^
6 errors generated.
This is because on FreeBSD, the pthread functions have lock annotations.
Since the functions in __thread_support are internal to libc++ only, add
no_thread_safety_analysis attributes to suppress these warnings.
Reviewers: mclow.lists, EricWF, delesley, aaron.ballman
Reviewed By: aaron.ballman
Subscribers: ed, aaron.ballman, joerg, emaste, cfe-commits
Differential Revision: https://reviews.llvm.org/D28520
llvm-svn: 293197
2017-01-27 02:37:18 +08:00
|
|
|
_LIBCPP_THREAD_ABI_VISIBILITY _LIBCPP_NO_THREAD_SAFETY_ANALYSIS
|
2017-01-14 18:27:12 +08:00
|
|
|
bool __libcpp_mutex_trylock(__libcpp_mutex_t *__m);
|
2017-01-03 10:00:31 +08:00
|
|
|
|
Disable thread safety analysis for some functions in __thread_support
Many thread-related libc++ test cases fail on FreeBSD, due to the
following -Werror warnings:
In file included from test/std/thread/thread.threads/thread.thread.this/sleep_until.pass.cpp:17:
In file included from include/thread:97:
In file included from include/__mutex_base:17:
include/__threading_support:222:1: error: mutex '__m' is still held at the end of function [-Werror,-Wthread-safety-analysis]
}
^
include/__threading_support:221:10: note: mutex acquired here
return pthread_mutex_lock(__m);
^
include/__threading_support:231:10: error: releasing mutex '__m' that was not held [-Werror,-Wthread-safety-analysis]
return pthread_mutex_unlock(__m);
^
include/__threading_support:242:1: error: mutex '__m' is still held at the end of function [-Werror,-Wthread-safety-analysis]
}
^
include/__threading_support:241:10: note: mutex acquired here
return pthread_mutex_lock(__m);
^
include/__threading_support:251:10: error: releasing mutex '__m' that was not held [-Werror,-Wthread-safety-analysis]
return pthread_mutex_unlock(__m);
^
include/__threading_support:272:10: error: calling function 'pthread_cond_wait' requires holding mutex '__m' exclusively [-Werror,-Wthread-safety-analysis]
return pthread_cond_wait(__cv, __m);
^
include/__threading_support:278:10: error: calling function 'pthread_cond_timedwait' requires holding mutex '__m' exclusively [-Werror,-Wthread-safety-analysis]
return pthread_cond_timedwait(__cv, __m, __ts);
^
6 errors generated.
This is because on FreeBSD, the pthread functions have lock annotations.
Since the functions in __thread_support are internal to libc++ only, add
no_thread_safety_analysis attributes to suppress these warnings.
Reviewers: mclow.lists, EricWF, delesley, aaron.ballman
Reviewed By: aaron.ballman
Subscribers: ed, aaron.ballman, joerg, emaste, cfe-commits
Differential Revision: https://reviews.llvm.org/D28520
llvm-svn: 293197
2017-01-27 02:37:18 +08:00
|
|
|
_LIBCPP_THREAD_ABI_VISIBILITY _LIBCPP_NO_THREAD_SAFETY_ANALYSIS
|
2017-01-03 10:00:31 +08:00
|
|
|
int __libcpp_mutex_unlock(__libcpp_mutex_t *__m);
|
|
|
|
|
[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_THREAD_ABI_VISIBILITY
|
2017-01-03 10:00:31 +08:00
|
|
|
int __libcpp_mutex_destroy(__libcpp_mutex_t *__m);
|
[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
|
|
|
|
|
|
|
// Condition variable
|
|
|
|
_LIBCPP_THREAD_ABI_VISIBILITY
|
|
|
|
int __libcpp_condvar_signal(__libcpp_condvar_t* __cv);
|
2017-01-03 10:00:31 +08:00
|
|
|
|
[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_THREAD_ABI_VISIBILITY
|
|
|
|
int __libcpp_condvar_broadcast(__libcpp_condvar_t* __cv);
|
2017-01-03 10:00:31 +08:00
|
|
|
|
Disable thread safety analysis for some functions in __thread_support
Many thread-related libc++ test cases fail on FreeBSD, due to the
following -Werror warnings:
In file included from test/std/thread/thread.threads/thread.thread.this/sleep_until.pass.cpp:17:
In file included from include/thread:97:
In file included from include/__mutex_base:17:
include/__threading_support:222:1: error: mutex '__m' is still held at the end of function [-Werror,-Wthread-safety-analysis]
}
^
include/__threading_support:221:10: note: mutex acquired here
return pthread_mutex_lock(__m);
^
include/__threading_support:231:10: error: releasing mutex '__m' that was not held [-Werror,-Wthread-safety-analysis]
return pthread_mutex_unlock(__m);
^
include/__threading_support:242:1: error: mutex '__m' is still held at the end of function [-Werror,-Wthread-safety-analysis]
}
^
include/__threading_support:241:10: note: mutex acquired here
return pthread_mutex_lock(__m);
^
include/__threading_support:251:10: error: releasing mutex '__m' that was not held [-Werror,-Wthread-safety-analysis]
return pthread_mutex_unlock(__m);
^
include/__threading_support:272:10: error: calling function 'pthread_cond_wait' requires holding mutex '__m' exclusively [-Werror,-Wthread-safety-analysis]
return pthread_cond_wait(__cv, __m);
^
include/__threading_support:278:10: error: calling function 'pthread_cond_timedwait' requires holding mutex '__m' exclusively [-Werror,-Wthread-safety-analysis]
return pthread_cond_timedwait(__cv, __m, __ts);
^
6 errors generated.
This is because on FreeBSD, the pthread functions have lock annotations.
Since the functions in __thread_support are internal to libc++ only, add
no_thread_safety_analysis attributes to suppress these warnings.
Reviewers: mclow.lists, EricWF, delesley, aaron.ballman
Reviewed By: aaron.ballman
Subscribers: ed, aaron.ballman, joerg, emaste, cfe-commits
Differential Revision: https://reviews.llvm.org/D28520
llvm-svn: 293197
2017-01-27 02:37:18 +08:00
|
|
|
_LIBCPP_THREAD_ABI_VISIBILITY _LIBCPP_NO_THREAD_SAFETY_ANALYSIS
|
[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 __libcpp_condvar_wait(__libcpp_condvar_t* __cv, __libcpp_mutex_t* __m);
|
2017-01-03 10:00:31 +08:00
|
|
|
|
Disable thread safety analysis for some functions in __thread_support
Many thread-related libc++ test cases fail on FreeBSD, due to the
following -Werror warnings:
In file included from test/std/thread/thread.threads/thread.thread.this/sleep_until.pass.cpp:17:
In file included from include/thread:97:
In file included from include/__mutex_base:17:
include/__threading_support:222:1: error: mutex '__m' is still held at the end of function [-Werror,-Wthread-safety-analysis]
}
^
include/__threading_support:221:10: note: mutex acquired here
return pthread_mutex_lock(__m);
^
include/__threading_support:231:10: error: releasing mutex '__m' that was not held [-Werror,-Wthread-safety-analysis]
return pthread_mutex_unlock(__m);
^
include/__threading_support:242:1: error: mutex '__m' is still held at the end of function [-Werror,-Wthread-safety-analysis]
}
^
include/__threading_support:241:10: note: mutex acquired here
return pthread_mutex_lock(__m);
^
include/__threading_support:251:10: error: releasing mutex '__m' that was not held [-Werror,-Wthread-safety-analysis]
return pthread_mutex_unlock(__m);
^
include/__threading_support:272:10: error: calling function 'pthread_cond_wait' requires holding mutex '__m' exclusively [-Werror,-Wthread-safety-analysis]
return pthread_cond_wait(__cv, __m);
^
include/__threading_support:278:10: error: calling function 'pthread_cond_timedwait' requires holding mutex '__m' exclusively [-Werror,-Wthread-safety-analysis]
return pthread_cond_timedwait(__cv, __m, __ts);
^
6 errors generated.
This is because on FreeBSD, the pthread functions have lock annotations.
Since the functions in __thread_support are internal to libc++ only, add
no_thread_safety_analysis attributes to suppress these warnings.
Reviewers: mclow.lists, EricWF, delesley, aaron.ballman
Reviewed By: aaron.ballman
Subscribers: ed, aaron.ballman, joerg, emaste, cfe-commits
Differential Revision: https://reviews.llvm.org/D28520
llvm-svn: 293197
2017-01-27 02:37:18 +08:00
|
|
|
_LIBCPP_THREAD_ABI_VISIBILITY _LIBCPP_NO_THREAD_SAFETY_ANALYSIS
|
2017-01-03 10:00:31 +08:00
|
|
|
int __libcpp_condvar_timedwait(__libcpp_condvar_t *__cv, __libcpp_mutex_t *__m,
|
2019-06-21 16:33:47 +08:00
|
|
|
__libcpp_timespec_t *__ts);
|
2017-01-03 10:00:31 +08:00
|
|
|
|
[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_THREAD_ABI_VISIBILITY
|
|
|
|
int __libcpp_condvar_destroy(__libcpp_condvar_t* __cv);
|
|
|
|
|
2020-02-27 08:49:37 +08:00
|
|
|
#ifndef _LIBCPP_NO_NATIVE_SEMAPHORES
|
|
|
|
|
2020-02-18 22:58:34 +08:00
|
|
|
// Semaphore
|
|
|
|
_LIBCPP_THREAD_ABI_VISIBILITY
|
|
|
|
bool __libcpp_semaphore_init(__libcpp_semaphore_t* __sem, int __init);
|
|
|
|
|
|
|
|
_LIBCPP_THREAD_ABI_VISIBILITY
|
|
|
|
bool __libcpp_semaphore_destroy(__libcpp_semaphore_t* __sem);
|
|
|
|
|
|
|
|
_LIBCPP_THREAD_ABI_VISIBILITY
|
|
|
|
bool __libcpp_semaphore_post(__libcpp_semaphore_t* __sem);
|
|
|
|
|
|
|
|
_LIBCPP_THREAD_ABI_VISIBILITY
|
|
|
|
bool __libcpp_semaphore_wait(__libcpp_semaphore_t* __sem);
|
|
|
|
|
|
|
|
_LIBCPP_THREAD_ABI_VISIBILITY
|
|
|
|
bool __libcpp_semaphore_wait_timed(__libcpp_semaphore_t* __sem, chrono::nanoseconds const& __ns);
|
|
|
|
|
2020-02-27 08:49:37 +08:00
|
|
|
#endif // _LIBCPP_NO_NATIVE_SEMAPHORES
|
|
|
|
|
2017-01-03 20:59:50 +08:00
|
|
|
// Execute once
|
|
|
|
_LIBCPP_THREAD_ABI_VISIBILITY
|
|
|
|
int __libcpp_execute_once(__libcpp_exec_once_flag *flag,
|
2019-07-02 00:18:38 +08:00
|
|
|
void (*init_routine)());
|
2017-01-03 20:59:50 +08:00
|
|
|
|
|
|
|
// Thread id
|
[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_THREAD_ABI_VISIBILITY
|
|
|
|
bool __libcpp_thread_id_equal(__libcpp_thread_id t1, __libcpp_thread_id t2);
|
2017-01-03 10:00:31 +08:00
|
|
|
|
[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_THREAD_ABI_VISIBILITY
|
|
|
|
bool __libcpp_thread_id_less(__libcpp_thread_id t1, __libcpp_thread_id t2);
|
|
|
|
|
|
|
|
// Thread
|
2017-01-16 20:19:54 +08:00
|
|
|
_LIBCPP_THREAD_ABI_VISIBILITY
|
|
|
|
bool __libcpp_thread_isnull(const __libcpp_thread_t *__t);
|
|
|
|
|
[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_THREAD_ABI_VISIBILITY
|
2017-01-03 10:00:31 +08:00
|
|
|
int __libcpp_thread_create(__libcpp_thread_t *__t, void *(*__func)(void *),
|
|
|
|
void *__arg);
|
|
|
|
|
[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_THREAD_ABI_VISIBILITY
|
|
|
|
__libcpp_thread_id __libcpp_thread_get_current_id();
|
2017-01-03 10:00:31 +08:00
|
|
|
|
[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_THREAD_ABI_VISIBILITY
|
2017-01-03 10:00:31 +08:00
|
|
|
__libcpp_thread_id __libcpp_thread_get_id(const __libcpp_thread_t *__t);
|
|
|
|
|
[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_THREAD_ABI_VISIBILITY
|
2017-01-03 10:00:31 +08:00
|
|
|
int __libcpp_thread_join(__libcpp_thread_t *__t);
|
|
|
|
|
[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_THREAD_ABI_VISIBILITY
|
2017-01-03 10:00:31 +08:00
|
|
|
int __libcpp_thread_detach(__libcpp_thread_t *__t);
|
|
|
|
|
[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_THREAD_ABI_VISIBILITY
|
|
|
|
void __libcpp_thread_yield();
|
|
|
|
|
2017-02-09 17:31:41 +08:00
|
|
|
_LIBCPP_THREAD_ABI_VISIBILITY
|
2017-02-09 22:12:29 +08:00
|
|
|
void __libcpp_thread_sleep_for(const chrono::nanoseconds& __ns);
|
2017-02-09 17:31:41 +08:00
|
|
|
|
[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
|
|
|
// Thread local storage
|
|
|
|
_LIBCPP_THREAD_ABI_VISIBILITY
|
2017-01-07 11:07:45 +08:00
|
|
|
int __libcpp_tls_create(__libcpp_tls_key* __key,
|
|
|
|
void(_LIBCPP_TLS_DESTRUCTOR_CC* __at_exit)(void*));
|
2017-01-03 10:00:31 +08:00
|
|
|
|
[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_THREAD_ABI_VISIBILITY
|
2017-01-03 10:00:31 +08:00
|
|
|
void *__libcpp_tls_get(__libcpp_tls_key __key);
|
|
|
|
|
[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_THREAD_ABI_VISIBILITY
|
2017-01-03 20:59:50 +08:00
|
|
|
int __libcpp_tls_set(__libcpp_tls_key __key, void *__p);
|
[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
|
|
|
|
2019-08-21 23:38:24 +08:00
|
|
|
#endif // !defined(_LIBCPP_HAS_THREAD_API_EXTERNAL)
|
|
|
|
|
2020-02-27 01:54:43 +08:00
|
|
|
struct __libcpp_timed_backoff_policy {
|
2020-08-28 01:09:23 +08:00
|
|
|
_LIBCPP_INLINE_VISIBILITY
|
|
|
|
bool operator()(chrono::nanoseconds __elapsed) const
|
|
|
|
{
|
|
|
|
if(__elapsed > chrono::milliseconds(128))
|
|
|
|
__libcpp_thread_sleep_for(chrono::milliseconds(8));
|
|
|
|
else if(__elapsed > chrono::microseconds(64))
|
|
|
|
__libcpp_thread_sleep_for(__elapsed / 2);
|
|
|
|
else if(__elapsed > chrono::microseconds(4))
|
|
|
|
__libcpp_thread_yield();
|
|
|
|
else
|
|
|
|
; // poll
|
|
|
|
return false;
|
|
|
|
}
|
2020-02-27 01:54:43 +08:00
|
|
|
};
|
|
|
|
|
2020-05-21 20:46:42 +08:00
|
|
|
static _LIBCPP_CONSTEXPR const int __libcpp_polling_count = 64;
|
|
|
|
|
2020-02-27 01:54:43 +08:00
|
|
|
template<class _Fn, class _BFn>
|
2020-02-24 23:09:29 +08:00
|
|
|
_LIBCPP_AVAILABILITY_SYNC _LIBCPP_INLINE_VISIBILITY
|
2020-02-27 01:54:43 +08:00
|
|
|
bool __libcpp_thread_poll_with_backoff(
|
2020-05-21 20:46:42 +08:00
|
|
|
_Fn && __f, _BFn && __bf, chrono::nanoseconds __max_elapsed = chrono::nanoseconds::zero())
|
|
|
|
{
|
|
|
|
auto const __start = chrono::high_resolution_clock::now();
|
|
|
|
for(int __count = 0;;) {
|
|
|
|
if(__f())
|
|
|
|
return true; // _Fn completion means success
|
|
|
|
if(__count < __libcpp_polling_count) {
|
|
|
|
__count += 1;
|
|
|
|
continue;
|
|
|
|
}
|
|
|
|
chrono::nanoseconds const __elapsed = chrono::high_resolution_clock::now() - __start;
|
|
|
|
if(__max_elapsed != chrono::nanoseconds::zero() && __max_elapsed < __elapsed)
|
|
|
|
return false; // timeout failure
|
|
|
|
if(__bf(__elapsed))
|
|
|
|
return false; // _BFn completion means failure
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
#if (!defined(_LIBCPP_HAS_THREAD_LIBRARY_EXTERNAL) || \
|
|
|
|
defined(_LIBCPP_BUILDING_THREAD_LIBRARY_EXTERNAL))
|
|
|
|
|
2020-02-27 01:54:43 +08:00
|
|
|
|
2019-12-05 02:38:22 +08:00
|
|
|
namespace __thread_detail {
|
|
|
|
|
|
|
|
inline __libcpp_timespec_t __convert_to_timespec(const chrono::nanoseconds& __ns)
|
|
|
|
{
|
|
|
|
using namespace chrono;
|
|
|
|
seconds __s = duration_cast<seconds>(__ns);
|
|
|
|
__libcpp_timespec_t __ts;
|
|
|
|
typedef decltype(__ts.tv_sec) __ts_sec;
|
|
|
|
const __ts_sec __ts_sec_max = numeric_limits<__ts_sec>::max();
|
|
|
|
|
|
|
|
if (__s.count() < __ts_sec_max)
|
|
|
|
{
|
|
|
|
__ts.tv_sec = static_cast<__ts_sec>(__s.count());
|
|
|
|
__ts.tv_nsec = static_cast<decltype(__ts.tv_nsec)>((__ns - __s).count());
|
|
|
|
}
|
|
|
|
else
|
|
|
|
{
|
|
|
|
__ts.tv_sec = __ts_sec_max;
|
|
|
|
__ts.tv_nsec = 999999999; // (10^9 - 1)
|
|
|
|
}
|
|
|
|
|
|
|
|
return __ts;
|
|
|
|
}
|
|
|
|
|
|
|
|
}
|
|
|
|
|
|
|
|
#if defined(_LIBCPP_HAS_THREAD_API_PTHREAD)
|
2016-05-06 22:06:29 +08:00
|
|
|
|
2017-01-06 01:54:45 +08:00
|
|
|
int __libcpp_recursive_mutex_init(__libcpp_recursive_mutex_t *__m)
|
2016-05-06 22:06:29 +08:00
|
|
|
{
|
2017-01-03 10:00:31 +08:00
|
|
|
pthread_mutexattr_t attr;
|
|
|
|
int __ec = pthread_mutexattr_init(&attr);
|
|
|
|
if (__ec)
|
|
|
|
return __ec;
|
|
|
|
__ec = pthread_mutexattr_settype(&attr, PTHREAD_MUTEX_RECURSIVE);
|
|
|
|
if (__ec) {
|
|
|
|
pthread_mutexattr_destroy(&attr);
|
|
|
|
return __ec;
|
|
|
|
}
|
|
|
|
__ec = pthread_mutex_init(__m, &attr);
|
|
|
|
if (__ec) {
|
|
|
|
pthread_mutexattr_destroy(&attr);
|
|
|
|
return __ec;
|
|
|
|
}
|
|
|
|
__ec = pthread_mutexattr_destroy(&attr);
|
|
|
|
if (__ec) {
|
|
|
|
pthread_mutex_destroy(__m);
|
|
|
|
return __ec;
|
|
|
|
}
|
|
|
|
return 0;
|
2016-05-06 22:06:29 +08:00
|
|
|
}
|
|
|
|
|
2017-01-06 01:54:45 +08:00
|
|
|
int __libcpp_recursive_mutex_lock(__libcpp_recursive_mutex_t *__m)
|
|
|
|
{
|
|
|
|
return pthread_mutex_lock(__m);
|
|
|
|
}
|
|
|
|
|
2017-01-14 18:27:12 +08:00
|
|
|
bool __libcpp_recursive_mutex_trylock(__libcpp_recursive_mutex_t *__m)
|
2017-01-06 01:54:45 +08:00
|
|
|
{
|
2017-01-14 18:27:12 +08:00
|
|
|
return pthread_mutex_trylock(__m) == 0;
|
2017-01-06 01:54:45 +08:00
|
|
|
}
|
|
|
|
|
|
|
|
int __libcpp_recursive_mutex_unlock(__libcpp_mutex_t *__m)
|
|
|
|
{
|
|
|
|
return pthread_mutex_unlock(__m);
|
|
|
|
}
|
|
|
|
|
|
|
|
int __libcpp_recursive_mutex_destroy(__libcpp_recursive_mutex_t *__m)
|
|
|
|
{
|
|
|
|
return pthread_mutex_destroy(__m);
|
|
|
|
}
|
|
|
|
|
2017-01-03 10:00:31 +08:00
|
|
|
int __libcpp_mutex_lock(__libcpp_mutex_t *__m)
|
2016-05-06 22:06:29 +08:00
|
|
|
{
|
2017-01-03 10:00:31 +08:00
|
|
|
return pthread_mutex_lock(__m);
|
2016-05-06 22:06:29 +08:00
|
|
|
}
|
|
|
|
|
2017-01-14 18:27:12 +08:00
|
|
|
bool __libcpp_mutex_trylock(__libcpp_mutex_t *__m)
|
2016-05-06 22:06:29 +08:00
|
|
|
{
|
2017-01-14 18:27:12 +08:00
|
|
|
return pthread_mutex_trylock(__m) == 0;
|
2016-05-06 22:06:29 +08:00
|
|
|
}
|
|
|
|
|
2017-01-03 10:00:31 +08:00
|
|
|
int __libcpp_mutex_unlock(__libcpp_mutex_t *__m)
|
2016-05-06 22:06:29 +08:00
|
|
|
{
|
2017-01-03 10:00:31 +08:00
|
|
|
return pthread_mutex_unlock(__m);
|
2016-05-06 22:06:29 +08:00
|
|
|
}
|
|
|
|
|
2017-01-03 10:00:31 +08:00
|
|
|
int __libcpp_mutex_destroy(__libcpp_mutex_t *__m)
|
2016-05-06 22:06:29 +08:00
|
|
|
{
|
2017-01-03 10:00:31 +08:00
|
|
|
return pthread_mutex_destroy(__m);
|
2016-05-06 22:06:29 +08:00
|
|
|
}
|
|
|
|
|
2017-01-03 10:00:31 +08:00
|
|
|
// Condition Variable
|
|
|
|
int __libcpp_condvar_signal(__libcpp_condvar_t *__cv)
|
2016-05-06 22:06:29 +08:00
|
|
|
{
|
2017-01-03 10:00:31 +08:00
|
|
|
return pthread_cond_signal(__cv);
|
2016-05-06 22:06:29 +08:00
|
|
|
}
|
|
|
|
|
2017-01-03 10:00:31 +08:00
|
|
|
int __libcpp_condvar_broadcast(__libcpp_condvar_t *__cv)
|
2016-05-06 22:06:29 +08:00
|
|
|
{
|
2017-01-03 10:00:31 +08:00
|
|
|
return pthread_cond_broadcast(__cv);
|
2016-05-06 22:06:29 +08:00
|
|
|
}
|
|
|
|
|
2017-01-03 10:00:31 +08:00
|
|
|
int __libcpp_condvar_wait(__libcpp_condvar_t *__cv, __libcpp_mutex_t *__m)
|
2016-05-06 22:06:29 +08:00
|
|
|
{
|
2017-01-03 10:00:31 +08:00
|
|
|
return pthread_cond_wait(__cv, __m);
|
2016-05-06 22:06:29 +08:00
|
|
|
}
|
|
|
|
|
2017-01-03 10:00:31 +08:00
|
|
|
int __libcpp_condvar_timedwait(__libcpp_condvar_t *__cv, __libcpp_mutex_t *__m,
|
2019-06-21 16:33:47 +08:00
|
|
|
__libcpp_timespec_t *__ts)
|
2016-05-06 22:06:29 +08:00
|
|
|
{
|
2017-01-03 10:00:31 +08:00
|
|
|
return pthread_cond_timedwait(__cv, __m, __ts);
|
2016-05-06 22:06:29 +08:00
|
|
|
}
|
|
|
|
|
2017-01-03 10:00:31 +08:00
|
|
|
int __libcpp_condvar_destroy(__libcpp_condvar_t *__cv)
|
2016-05-06 22:06:29 +08:00
|
|
|
{
|
2017-01-03 10:00:31 +08:00
|
|
|
return pthread_cond_destroy(__cv);
|
2016-05-06 22:06:29 +08:00
|
|
|
}
|
|
|
|
|
2020-02-18 22:58:34 +08:00
|
|
|
#ifndef _LIBCPP_NO_NATIVE_SEMAPHORES
|
|
|
|
|
|
|
|
// Semaphore
|
|
|
|
bool __libcpp_semaphore_init(__libcpp_semaphore_t* __sem, int __init)
|
|
|
|
{
|
|
|
|
return sem_init(__sem, 0, __init) == 0;
|
|
|
|
}
|
|
|
|
|
|
|
|
bool __libcpp_semaphore_destroy(__libcpp_semaphore_t* __sem)
|
|
|
|
{
|
|
|
|
return sem_destroy(__sem) == 0;
|
|
|
|
}
|
|
|
|
|
|
|
|
bool __libcpp_semaphore_post(__libcpp_semaphore_t* __sem)
|
|
|
|
{
|
|
|
|
return sem_post(__sem) == 0;
|
|
|
|
}
|
|
|
|
|
|
|
|
bool __libcpp_semaphore_wait(__libcpp_semaphore_t* __sem)
|
|
|
|
{
|
|
|
|
return sem_wait(__sem) == 0;
|
|
|
|
}
|
|
|
|
|
|
|
|
bool __libcpp_semaphore_wait_timed(__libcpp_semaphore_t* __sem, chrono::nanoseconds const& __ns)
|
|
|
|
{
|
|
|
|
auto const __abs_time = chrono::system_clock::now().time_since_epoch() + __ns;
|
|
|
|
__libcpp_timespec_t __ts = __thread_detail::__convert_to_timespec(__abs_time);
|
|
|
|
return sem_timedwait(__sem, &__ts) == 0;
|
|
|
|
}
|
|
|
|
|
|
|
|
#endif //_LIBCPP_NO_NATIVE_SEMAPHORES
|
|
|
|
|
2017-01-03 20:59:50 +08:00
|
|
|
// Execute once
|
|
|
|
int __libcpp_execute_once(__libcpp_exec_once_flag *flag,
|
2019-07-02 00:18:38 +08:00
|
|
|
void (*init_routine)()) {
|
2017-01-03 20:59:50 +08:00
|
|
|
return pthread_once(flag, init_routine);
|
|
|
|
}
|
|
|
|
|
|
|
|
// Thread id
|
2016-05-06 22:06:29 +08:00
|
|
|
// Returns non-zero if the thread ids are equal, otherwise 0
|
|
|
|
bool __libcpp_thread_id_equal(__libcpp_thread_id t1, __libcpp_thread_id t2)
|
|
|
|
{
|
2017-01-03 10:00:31 +08:00
|
|
|
return pthread_equal(t1, t2) != 0;
|
2016-05-06 22:06:29 +08:00
|
|
|
}
|
|
|
|
|
|
|
|
// Returns non-zero if t1 < t2, otherwise 0
|
|
|
|
bool __libcpp_thread_id_less(__libcpp_thread_id t1, __libcpp_thread_id t2)
|
|
|
|
{
|
2017-01-03 10:00:31 +08:00
|
|
|
return t1 < t2;
|
2016-05-06 22:06:29 +08:00
|
|
|
}
|
|
|
|
|
|
|
|
// Thread
|
2017-01-16 20:19:54 +08:00
|
|
|
bool __libcpp_thread_isnull(const __libcpp_thread_t *__t) {
|
|
|
|
return *__t == 0;
|
|
|
|
}
|
|
|
|
|
2017-01-03 10:00:31 +08:00
|
|
|
int __libcpp_thread_create(__libcpp_thread_t *__t, void *(*__func)(void *),
|
|
|
|
void *__arg)
|
2016-05-06 22:06:29 +08:00
|
|
|
{
|
2017-01-03 10:00:31 +08:00
|
|
|
return pthread_create(__t, 0, __func, __arg);
|
2016-05-06 22:06:29 +08:00
|
|
|
}
|
|
|
|
|
|
|
|
__libcpp_thread_id __libcpp_thread_get_current_id()
|
|
|
|
{
|
2017-01-03 10:00:31 +08:00
|
|
|
return pthread_self();
|
2016-05-06 22:06:29 +08:00
|
|
|
}
|
|
|
|
|
2017-01-03 10:00:31 +08:00
|
|
|
__libcpp_thread_id __libcpp_thread_get_id(const __libcpp_thread_t *__t)
|
2016-05-06 22:06:29 +08:00
|
|
|
{
|
2017-01-03 10:00:31 +08:00
|
|
|
return *__t;
|
2016-05-06 22:06:29 +08:00
|
|
|
}
|
|
|
|
|
2017-01-03 10:00:31 +08:00
|
|
|
int __libcpp_thread_join(__libcpp_thread_t *__t)
|
2016-05-06 22:06:29 +08:00
|
|
|
{
|
2017-01-03 10:00:31 +08:00
|
|
|
return pthread_join(*__t, 0);
|
2016-05-06 22:06:29 +08:00
|
|
|
}
|
|
|
|
|
2017-01-03 10:00:31 +08:00
|
|
|
int __libcpp_thread_detach(__libcpp_thread_t *__t)
|
2016-05-06 22:06:29 +08:00
|
|
|
{
|
2017-01-03 10:00:31 +08:00
|
|
|
return pthread_detach(*__t);
|
2016-05-06 22:06:29 +08:00
|
|
|
}
|
|
|
|
|
|
|
|
void __libcpp_thread_yield()
|
|
|
|
{
|
2017-01-03 10:00:31 +08:00
|
|
|
sched_yield();
|
2016-05-06 22:06:29 +08:00
|
|
|
}
|
|
|
|
|
2017-02-09 17:31:41 +08:00
|
|
|
void __libcpp_thread_sleep_for(const chrono::nanoseconds& __ns)
|
|
|
|
{
|
2019-12-05 02:38:22 +08:00
|
|
|
__libcpp_timespec_t __ts = __thread_detail::__convert_to_timespec(__ns);
|
2017-02-09 17:31:41 +08:00
|
|
|
while (nanosleep(&__ts, &__ts) == -1 && errno == EINTR);
|
|
|
|
}
|
|
|
|
|
2016-05-06 22:06:29 +08:00
|
|
|
// Thread local storage
|
2017-01-03 10:00:31 +08:00
|
|
|
int __libcpp_tls_create(__libcpp_tls_key *__key, void (*__at_exit)(void *))
|
2016-05-06 22:06:29 +08:00
|
|
|
{
|
2017-01-03 10:00:31 +08:00
|
|
|
return pthread_key_create(__key, __at_exit);
|
2016-05-06 22:06:29 +08:00
|
|
|
}
|
|
|
|
|
2017-01-03 10:00:31 +08:00
|
|
|
void *__libcpp_tls_get(__libcpp_tls_key __key)
|
2016-05-06 22:06:29 +08:00
|
|
|
{
|
2017-01-03 10:00:31 +08:00
|
|
|
return pthread_getspecific(__key);
|
2016-05-06 22:06:29 +08:00
|
|
|
}
|
|
|
|
|
2017-01-03 20:59:50 +08:00
|
|
|
int __libcpp_tls_set(__libcpp_tls_key __key, void *__p)
|
2016-05-06 22:06:29 +08:00
|
|
|
{
|
2017-01-03 20:59:50 +08:00
|
|
|
return pthread_setspecific(__key, __p);
|
2016-05-06 22:06:29 +08:00
|
|
|
}
|
|
|
|
|
2019-12-05 02:38:22 +08:00
|
|
|
#elif defined(_LIBCPP_HAS_THREAD_API_C11)
|
|
|
|
|
|
|
|
int __libcpp_recursive_mutex_init(__libcpp_recursive_mutex_t *__m)
|
|
|
|
{
|
2020-01-16 05:58:29 +08:00
|
|
|
return mtx_init(__m, mtx_plain | mtx_recursive) == thrd_success ? 0 : EINVAL;
|
2019-12-05 02:38:22 +08:00
|
|
|
}
|
|
|
|
|
|
|
|
int __libcpp_recursive_mutex_lock(__libcpp_recursive_mutex_t *__m)
|
|
|
|
{
|
|
|
|
return mtx_lock(__m) == thrd_success ? 0 : EINVAL;
|
|
|
|
}
|
|
|
|
|
|
|
|
bool __libcpp_recursive_mutex_trylock(__libcpp_recursive_mutex_t *__m)
|
|
|
|
{
|
|
|
|
return mtx_trylock(__m) == thrd_success;
|
|
|
|
}
|
|
|
|
|
|
|
|
int __libcpp_recursive_mutex_unlock(__libcpp_mutex_t *__m)
|
|
|
|
{
|
|
|
|
return mtx_unlock(__m) == thrd_success ? 0 : EINVAL;
|
|
|
|
}
|
|
|
|
|
|
|
|
int __libcpp_recursive_mutex_destroy(__libcpp_recursive_mutex_t *__m)
|
|
|
|
{
|
|
|
|
mtx_destroy(__m);
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
|
|
|
int __libcpp_mutex_lock(__libcpp_mutex_t *__m)
|
|
|
|
{
|
|
|
|
return mtx_lock(__m) == thrd_success ? 0 : EINVAL;
|
|
|
|
}
|
|
|
|
|
|
|
|
bool __libcpp_mutex_trylock(__libcpp_mutex_t *__m)
|
|
|
|
{
|
|
|
|
return mtx_trylock(__m) == thrd_success;
|
|
|
|
}
|
|
|
|
|
|
|
|
int __libcpp_mutex_unlock(__libcpp_mutex_t *__m)
|
|
|
|
{
|
|
|
|
return mtx_unlock(__m) == thrd_success ? 0 : EINVAL;
|
|
|
|
}
|
|
|
|
|
|
|
|
int __libcpp_mutex_destroy(__libcpp_mutex_t *__m)
|
|
|
|
{
|
|
|
|
mtx_destroy(__m);
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
|
|
|
// Condition Variable
|
|
|
|
int __libcpp_condvar_signal(__libcpp_condvar_t *__cv)
|
|
|
|
{
|
|
|
|
return cnd_signal(__cv) == thrd_success ? 0 : EINVAL;
|
|
|
|
}
|
|
|
|
|
|
|
|
int __libcpp_condvar_broadcast(__libcpp_condvar_t *__cv)
|
|
|
|
{
|
|
|
|
return cnd_broadcast(__cv) == thrd_success ? 0 : EINVAL;
|
|
|
|
}
|
|
|
|
|
|
|
|
int __libcpp_condvar_wait(__libcpp_condvar_t *__cv, __libcpp_mutex_t *__m)
|
|
|
|
{
|
|
|
|
return cnd_wait(__cv, __m) == thrd_success ? 0 : EINVAL;
|
|
|
|
}
|
|
|
|
|
|
|
|
int __libcpp_condvar_timedwait(__libcpp_condvar_t *__cv, __libcpp_mutex_t *__m,
|
|
|
|
timespec *__ts)
|
|
|
|
{
|
|
|
|
int __ec = cnd_timedwait(__cv, __m, __ts);
|
|
|
|
return __ec == thrd_timedout ? ETIMEDOUT : __ec;
|
|
|
|
}
|
|
|
|
|
|
|
|
int __libcpp_condvar_destroy(__libcpp_condvar_t *__cv)
|
|
|
|
{
|
|
|
|
cnd_destroy(__cv);
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
|
|
|
// Execute once
|
|
|
|
int __libcpp_execute_once(__libcpp_exec_once_flag *flag,
|
|
|
|
void (*init_routine)(void)) {
|
|
|
|
::call_once(flag, init_routine);
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
|
|
|
// Thread id
|
|
|
|
// Returns non-zero if the thread ids are equal, otherwise 0
|
|
|
|
bool __libcpp_thread_id_equal(__libcpp_thread_id t1, __libcpp_thread_id t2)
|
|
|
|
{
|
|
|
|
return thrd_equal(t1, t2) != 0;
|
|
|
|
}
|
|
|
|
|
|
|
|
// Returns non-zero if t1 < t2, otherwise 0
|
|
|
|
bool __libcpp_thread_id_less(__libcpp_thread_id t1, __libcpp_thread_id t2)
|
|
|
|
{
|
|
|
|
return t1 < t2;
|
|
|
|
}
|
|
|
|
|
|
|
|
// Thread
|
|
|
|
bool __libcpp_thread_isnull(const __libcpp_thread_t *__t) {
|
|
|
|
return *__t == 0;
|
|
|
|
}
|
|
|
|
|
|
|
|
int __libcpp_thread_create(__libcpp_thread_t *__t, void *(*__func)(void *),
|
|
|
|
void *__arg)
|
|
|
|
{
|
|
|
|
int __ec = thrd_create(__t, reinterpret_cast<thrd_start_t>(__func), __arg);
|
|
|
|
return __ec == thrd_nomem ? ENOMEM : __ec;
|
|
|
|
}
|
|
|
|
|
|
|
|
__libcpp_thread_id __libcpp_thread_get_current_id()
|
|
|
|
{
|
|
|
|
return thrd_current();
|
|
|
|
}
|
|
|
|
|
|
|
|
__libcpp_thread_id __libcpp_thread_get_id(const __libcpp_thread_t *__t)
|
|
|
|
{
|
|
|
|
return *__t;
|
|
|
|
}
|
|
|
|
|
|
|
|
int __libcpp_thread_join(__libcpp_thread_t *__t)
|
|
|
|
{
|
|
|
|
return thrd_join(*__t, nullptr) == thrd_success ? 0 : EINVAL;
|
|
|
|
}
|
|
|
|
|
|
|
|
int __libcpp_thread_detach(__libcpp_thread_t *__t)
|
|
|
|
{
|
|
|
|
return thrd_detach(*__t) == thrd_success ? 0 : EINVAL;
|
|
|
|
}
|
|
|
|
|
|
|
|
void __libcpp_thread_yield()
|
|
|
|
{
|
|
|
|
thrd_yield();
|
|
|
|
}
|
|
|
|
|
|
|
|
void __libcpp_thread_sleep_for(const chrono::nanoseconds& __ns)
|
|
|
|
{
|
|
|
|
__libcpp_timespec_t __ts = __thread_detail::__convert_to_timespec(__ns);
|
|
|
|
thrd_sleep(&__ts, nullptr);
|
|
|
|
}
|
|
|
|
|
|
|
|
// Thread local storage
|
|
|
|
int __libcpp_tls_create(__libcpp_tls_key *__key, void (*__at_exit)(void *))
|
|
|
|
{
|
|
|
|
return tss_create(__key, __at_exit) == thrd_success ? 0 : EINVAL;
|
|
|
|
}
|
|
|
|
|
|
|
|
void *__libcpp_tls_get(__libcpp_tls_key __key)
|
|
|
|
{
|
|
|
|
return tss_get(__key);
|
|
|
|
}
|
|
|
|
|
|
|
|
int __libcpp_tls_set(__libcpp_tls_key __key, void *__p)
|
|
|
|
{
|
|
|
|
return tss_set(__key, __p) == thrd_success ? 0 : EINVAL;
|
|
|
|
}
|
|
|
|
|
|
|
|
#endif
|
|
|
|
|
2020-02-25 15:36:24 +08:00
|
|
|
|
2017-01-07 04:05:40 +08:00
|
|
|
#endif // !_LIBCPP_HAS_THREAD_LIBRARY_EXTERNAL || _LIBCPP_BUILDING_THREAD_LIBRARY_EXTERNAL
|
2016-05-06 22:06:29 +08:00
|
|
|
|
2019-08-15 00:21:27 +08:00
|
|
|
class _LIBCPP_TYPE_VIS thread;
|
|
|
|
class _LIBCPP_TYPE_VIS __thread_id;
|
|
|
|
|
|
|
|
namespace this_thread
|
|
|
|
{
|
|
|
|
|
|
|
|
_LIBCPP_INLINE_VISIBILITY __thread_id get_id() _NOEXCEPT;
|
|
|
|
|
|
|
|
} // this_thread
|
|
|
|
|
|
|
|
template<> struct hash<__thread_id>;
|
|
|
|
|
|
|
|
class _LIBCPP_TEMPLATE_VIS __thread_id
|
|
|
|
{
|
|
|
|
// 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_;
|
|
|
|
|
|
|
|
public:
|
|
|
|
_LIBCPP_INLINE_VISIBILITY
|
|
|
|
__thread_id() _NOEXCEPT : __id_(0) {}
|
|
|
|
|
|
|
|
friend _LIBCPP_INLINE_VISIBILITY
|
|
|
|
bool operator==(__thread_id __x, __thread_id __y) _NOEXCEPT
|
2019-08-15 04:54:56 +08:00
|
|
|
{ // don't pass id==0 to underlying routines
|
|
|
|
if (__x.__id_ == 0) return __y.__id_ == 0;
|
|
|
|
if (__y.__id_ == 0) return false;
|
|
|
|
return __libcpp_thread_id_equal(__x.__id_, __y.__id_);
|
|
|
|
}
|
2019-08-15 00:21:27 +08:00
|
|
|
friend _LIBCPP_INLINE_VISIBILITY
|
|
|
|
bool operator!=(__thread_id __x, __thread_id __y) _NOEXCEPT
|
|
|
|
{return !(__x == __y);}
|
|
|
|
friend _LIBCPP_INLINE_VISIBILITY
|
|
|
|
bool operator< (__thread_id __x, __thread_id __y) _NOEXCEPT
|
2019-08-15 04:54:56 +08:00
|
|
|
{ // id==0 is always less than any other thread_id
|
|
|
|
if (__x.__id_ == 0) return __y.__id_ != 0;
|
|
|
|
if (__y.__id_ == 0) return false;
|
|
|
|
return __libcpp_thread_id_less(__x.__id_, __y.__id_);
|
|
|
|
}
|
2019-08-15 00:21:27 +08:00
|
|
|
friend _LIBCPP_INLINE_VISIBILITY
|
|
|
|
bool operator<=(__thread_id __x, __thread_id __y) _NOEXCEPT
|
|
|
|
{return !(__y < __x);}
|
|
|
|
friend _LIBCPP_INLINE_VISIBILITY
|
|
|
|
bool operator> (__thread_id __x, __thread_id __y) _NOEXCEPT
|
|
|
|
{return __y < __x ;}
|
|
|
|
friend _LIBCPP_INLINE_VISIBILITY
|
|
|
|
bool operator>=(__thread_id __x, __thread_id __y) _NOEXCEPT
|
|
|
|
{return !(__x < __y);}
|
|
|
|
|
|
|
|
_LIBCPP_INLINE_VISIBILITY
|
2019-08-15 04:54:56 +08:00
|
|
|
void __reset() { __id_ = 0; }
|
2019-10-24 01:40:15 +08:00
|
|
|
|
2019-08-15 00:21:27 +08:00
|
|
|
template<class _CharT, class _Traits>
|
|
|
|
friend
|
|
|
|
_LIBCPP_INLINE_VISIBILITY
|
|
|
|
basic_ostream<_CharT, _Traits>&
|
|
|
|
operator<<(basic_ostream<_CharT, _Traits>& __os, __thread_id __id);
|
|
|
|
|
|
|
|
private:
|
|
|
|
_LIBCPP_INLINE_VISIBILITY
|
|
|
|
__thread_id(__libcpp_thread_id __id) : __id_(__id) {}
|
|
|
|
|
|
|
|
friend __thread_id this_thread::get_id() _NOEXCEPT;
|
|
|
|
friend class _LIBCPP_TYPE_VIS thread;
|
|
|
|
friend struct _LIBCPP_TEMPLATE_VIS hash<__thread_id>;
|
|
|
|
};
|
|
|
|
|
|
|
|
namespace this_thread
|
|
|
|
{
|
|
|
|
|
|
|
|
inline _LIBCPP_INLINE_VISIBILITY
|
|
|
|
__thread_id
|
|
|
|
get_id() _NOEXCEPT
|
|
|
|
{
|
|
|
|
return __libcpp_thread_get_current_id();
|
|
|
|
}
|
|
|
|
|
|
|
|
} // this_thread
|
|
|
|
|
2019-08-21 00:16:23 +08:00
|
|
|
#endif // !_LIBCPP_HAS_NO_THREADS
|
|
|
|
|
2017-01-07 04:05:40 +08:00
|
|
|
_LIBCPP_END_NAMESPACE_STD
|
2016-10-14 21:00:07 +08:00
|
|
|
|
2017-06-01 06:07:49 +08:00
|
|
|
_LIBCPP_POP_MACROS
|
|
|
|
|
2016-05-06 22:06:29 +08:00
|
|
|
#endif // _LIBCPP_THREADING_SUPPORT
|