summaryrefslogtreecommitdiffstats
path: root/libcxx/include/__threading_support
Commit message (Collapse)AuthorAgeFilesLines
* [libcxx] Use mtx_plain | mtx_recursive following C11 APIPetr Hosek2020-01-171-1/+1
| | | | | | | | | The C11 API specifies that to initialize a recursive mutex, mtx_plain | mtx_recursive should be used with mtx_init. Differential Revision: https://reviews.llvm.org/D72809 (cherry picked from commit 3481e5d7ed08d068a4e3427cb1afcd8bf2acafdc)
* [libcxx] Use C11 thread API on FuchsiaPetr Hosek2020-01-141-19/+220
| | | | | | | | | | | On Fuchsia, pthread API is emulated on top of C11 thread API. Using C11 thread API directly is more efficient. While this implementation is only used by Fuchsia at the moment, it's not Fuchsia specific, and could be used by other platforms that use C11 threads rather than pthreads in the future. Differential Revision: https://reviews.llvm.org/D64378
* [NFC] Strip trailing whitespace from libc++Louis Dionne2019-10-231-1/+1
|
* [libcxx] Only declare contents of threading API whenDavid Spickett2019-08-211-2/+5
| | | | | | | | | | | _LIBCPP_HAS_THREAD_API_EXTERNAL is not defined. When it is defined they will be declared by the __external_threading header instead. Differential revision: https://reviews.llvm.org/D66518 llvm-svn: 369537
* Fix availability of __thread_id on builds with external threading. Reviewed ↵Marshall Clow2019-08-201-8/+11
| | | | | | as https://reviews.llvm.org/D66480 llvm-svn: 369399
* Fix thread comparison by making sure we never pass our special 'not a ↵Marshall Clow2019-08-141-3/+11
| | | | | | thread' value to the underlying implementation. Fixes PR#42918. llvm-svn: 368916
* Rework recursive_timed_mutex so that it uses __thread_id instead of using ↵Marshall Clow2019-08-141-0/+73
| | | | | | the lower-level __libcpp_thread_id. This is prep for fixing PR42918. Reviewed as https://reviews.llvm.org/D65895 llvm-svn: 368867
* __threading_support: Remove (void) in favor of ().Bruce Mitchener2019-07-011-2/+2
| | | | | | | | | | | | | | Summary: This fixes a clang-tidy warning when building something that uses this file. Reviewers: mclow.lists, EricWF Subscribers: cfe-commits Differential Revision: https://reviews.llvm.org/D43226 llvm-svn: 364799
* [libc++] Avoid using timespec when it might not be availableMikhail Maltsev2019-06-211-3/+5
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: The type timespec is unconditionally used in __threading_support. Since the C library is only required to provide it in C11, this might cause problems for platforms with external thread porting layer (i.e. when _LIBCPP_HAS_THREAD_API_EXTERNAL is defined) with pre-C11 C libraries. In our downstream port of libc++ we used to provide a definition of timespec in __external_threading, but this solution is not ideal because timespec is not a reserved name. This patch renames timespec into __libcpp_timespec_t in the thread-related parts of libc++. For all cases except external threading this type is an alias for ::timespec (and no functional changes are intended). In case of external threading it is expected that the __external_threading header will either provide a similar typedef (if timespec is available in the vendor's C library) or provide a definition of __libcpp_timespec_t compatible with POSIX timespec. Reviewers: ldionne, mclow.lists, EricWF Reviewed By: ldionne Subscribers: dexonsmith, libcxx-commits, christof, carwil Tags: #libc Differential Revision: https://reviews.llvm.org/D63328 llvm-svn: 364012
* Update more file headers across all of the LLVM projects in the monorepoChandler Carruth2019-01-191-4/+3
| | | | | | | | | | | | | | | | | | to reflect the new license. These used slightly different spellings that defeated my regular expressions. We understand that people may be surprised that we're moving the header entirely to discuss the new license. We checked this carefully with the Foundation's lawyer and we believe this is the correct approach. Essentially, all code in the project is now made available by the LLVM project under our new license, so you will see that the license headers include that license only. Some of our contributors have contributed code under our old license, and accordingly, we have retained a copy of our old license notice in the top-level files in each project and repository. llvm-svn: 351648
* Fix typoFangrui Song2018-09-171-1/+1
| | | | llvm-svn: 342361
* libcxx: Unbreak external thread library configuration.Peter Collingbourne2018-02-211-12/+9
| | | | | | Differential Revision: https://reviews.llvm.org/D42503 llvm-svn: 325723
* libcxx: Move Windows threading support into a .cpp file.Peter Collingbourne2018-01-231-266/+32
| | | | | | | | | This allows us to avoid polluting the namespace of users of <thread> with the definitions in windows.h. Differential Revision: https://reviews.llvm.org/D42214 llvm-svn: 323169
* [Libc++] Use #pragma push_macro/pop_macro to better handle min/max on WindowsEric Fiselier2017-05-311-1/+6
| | | | | | | | | | | | | | | | Summary: This patch improves how libc++ handles min/max macros within the headers. Previously libc++ would undef them and emit a warning. This patch changes libc++ to use `#pragma push_macro` to save the macro before undefining it, and `#pragma pop_macro` to restore the macros and the end of the header. Reviewers: mclow.lists, bcraig, compnerd, EricWF Reviewed By: EricWF Subscribers: cfe-commits, krytarowski Differential Revision: https://reviews.llvm.org/D33080 llvm-svn: 304357
* libcxx: fix bootstrapping for mingw-w64Martell Malone2017-05-251-1/+1
| | | | | | Differential Revision: https://reviews.llvm.org/D33388 llvm-svn: 303928
* [libc++] Refactor Windows support headers.Eric Fiselier2017-05-101-0/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: This patch refactors and tries to remove as much of the Windows support headers as possible. This is needed because they currently introduce super weird include cycles and dependencies between STL and libc headers. The changes in this patch are: * remove `support/win32/support.h` completely. The required parts have either been moved into `support/win32/msvc_support.h` (for `MSVC` only helpers not needed by Clang), or directly into their respective `foo.h` headers. * Combine `locale_win32.h` and `locale_mgmt_win32.h` into a single headers, this header should only be included within `__locale` or `locale` to avoid include cycles. * Remove the unneeded parts of `limits_win32.h` and re-name it to `limits_msvc_win32.h` since it's only needed by Clang. I've tested this patch using Clang on Windows, but I suspect it might technically regress our non-existent support for MSVC. Is somebody able to double check? This refactor is needed to support upcoming fixes to `<locale>` on Windows. Reviewers: bcraig, rmaprath, compnerd, EricWF Reviewed By: EricWF Subscribers: majnemer, cfe-commits Differential Revision: https://reviews.llvm.org/D32988 llvm-svn: 302727
* Fix condition_variable::wait_until and wait_for on Windows.Eric Fiselier2017-05-051-1/+4
| | | | | | | | The ERROR_TIMEDOUT returned by the Windows API does not have the same value as ETIMEDOUT. This caused condition_variable to return timeouts as unknown errors. llvm-svn: 302297
* Revert "threading_support: make __thread_sleep_for be alertable"Saleem Abdulrasool2017-02-181-5/+3
| | | | | | | | | This reverts SVN r295329. Although `__libcpp_thread_sleep_for` should be alertable, the implementation causes a large regression in the test suite. Add a FIXME item there for now to get the test suite in a better state before attempting to fix that behaviour. llvm-svn: 295561
* threading_support: make __thread_sleep_for be alertableSaleem Abdulrasool2017-02-161-2/+5
| | | | | | | | | | On Windows, we were using `Sleep` which is not alertable. This means that if the thread was used for a user APC or WinProc handling and thread::sleep was used, we could potentially dead lock. Use `SleepEx` with an alertable sleep, resuming until the time has expired if we are awoken early. llvm-svn: 295329
* __threading_support: fix windows buildSaleem Abdulrasool2017-02-101-1/+2
| | | | | | | | The build was broken as there was no overload for long and std::chrono::nanoseconds. Add an explicit conversion to use the operator+. llvm-svn: 294698
* Use protected name for the prototype arguments.Joerg Sonnenberger2017-02-091-1/+1
| | | | llvm-svn: 294585
* Threading support: externalize sleep_for() function.Asiri Rathnayake2017-02-091-2/+35
| | | | | | | | | | Different platforms implement the wait/sleep functions in difrerent ways. It makes sense to externalize this into the threading API. Differential revision: https://reviews.llvm.org/D29630 Reviewers: EricWF, joerg llvm-svn: 294573
* Recommit [libcxx] Never use <cassert> within libc++Eric Fiselier2017-02-041-1/+0
| | | | | | | | | | It is my opinion that libc++ should never use `<cassert>`, including in the `dylib`. This patch remove all uses of `assert` from within libc++ and replaces most of them with `_LIBCPP_ASSERT` instead. Additionally this patch turn `LIBCXX_ENABLE_ASSERTIONS` off by default, because the standard library should not be aborting user programs unless explicitly asked to. llvm-svn: 294107
* Disable thread safety analysis for some functions in __thread_supportDimitry Andric2017-01-261-8/+14
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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
* Fix chromium build (libcxx)Asiri Rathnayake2017-01-261-11/+0
| | | | | | Remove the reference to pthread_mach_thread_np() in libcxx headers. llvm-svn: 293167
* Revert "[libcxx] Never use <cassert> within libc++"Eric Fiselier2017-01-241-0/+1
| | | | | | | | This reverts commit r292883. Unfortunately <string_view> uses _LIBCPP_ASSERT in a way which is not compatible with the C++11 dylib build. I'll investigate more tomorrow. llvm-svn: 292923
* [libcxx] Never use <cassert> within libc++Eric Fiselier2017-01-241-1/+0
| | | | | | | | | | | | | | | | | Summary: It is my opinion that libc++ should never use `<cassert>`, including in the `dylib`. This patch remove all uses of `assert` from within libc++ and replaces most of them with `_LIBCPP_ASSERT` instead. Additionally this patch turn `LIBCXX_ENABLE_ASSERTIONS` off by default, because the standard library should not be aborting user programs unless explicitly asked to. Reviewers: mclow.lists, compnerd, smeenai Reviewed By: mclow.lists Subscribers: mgorny, cfe-commits Differential Revision: https://reviews.llvm.org/D29063 llvm-svn: 292883
* [libcxx] Don't assume __libcpp_thread_t is an integral typeAsiri Rathnayake2017-01-161-0/+15
| | | | | | | | | | | | | We have already refactored the underlying platform thread type into __libcpp_thread_t, but there are few places in the source where we still assume it is an integral type. This patch refactores those points back into the threading API. Differential revision: https://reviews.llvm.org/D28608 Reviewers: EricWF llvm-svn: 292107
* Attempt two at fixing threading on WindowsEric Fiselier2017-01-141-9/+6
| | | | | | | | | | Reviewers: compnerd Subscribers: cfe-commits Differential Revision: https://reviews.llvm.org/D28735 llvm-svn: 292027
* Fix thread creation on WindowsEric Fiselier2017-01-141-13/+19
| | | | llvm-svn: 292022
* Fix Windows try_lock implementationEric Fiselier2017-01-141-12/+10
| | | | llvm-svn: 292011
* threading_support: delete the critical sectionSaleem Abdulrasool2017-01-101-1/+1
| | | | | | | Although the CriticalSection itself doesnt need to be destroyed, there may be debug data associated with it. Plug a possible small leak. llvm-svn: 291536
* provide Win32 native threadingSaleem Abdulrasool2017-01-071-1/+254
| | | | | | | | | | | Add an implementation for the Win32 threading model as a backing API for the internal c++ threading interfaces. This uses the Fls* family for the TLS (which has the support for adding termination callbacks), CRITICAL_SECTIONs for the recursive mutex, and Slim Reader/Writer locks (SRW locks) for non-recursive mutexes. These APIs should all be available on Vista or newer. llvm-svn: 291333
* [libc++] Cleanup and document <__threading_support>Eric Fiselier2017-01-061-37/+16
| | | | | | | | | | | | | | | Summary: This patch attempts to clean up the macro configuration mess in `<__threading_support>`, specifically the mess involving external threading variants. Additionally this patch adds design documentation for `<__threading_support>` and the configuration macros it uses. The primary change in this patch is separating the idea of an "external API" provided by `<__external_threading>` and the idea of having an external threading library. Now `_LIBCPP_HAS_THREAD_API_EXTERNAL` means that libc++ should use `<__external_threading>` and that the header is expected to exist. Additionally the new macro `_LIBCPP_HAS_THREAD_LIBRARY_EXTERNAL` is now used to configure for using an "external library" with the default threading API. Reviewers: compnerd, rmaprath Subscribers: smeenai, cfe-commits, mgorny Differential Revision: https://reviews.llvm.org/D28316 llvm-svn: 291275
* thread_support: split out {,non-}recursive mutexSaleem Abdulrasool2017-01-051-2/+36
| | | | | | | | Split out the recursive and non-recursive mutex. This split is needed for platforms which may use differing types for the two mutex (e.g. Win32 threads). llvm-svn: 291145
* [libcxx] Add build/test support for the externally threaded libc++abi variantAsiri Rathnayake2017-01-031-5/+32
| | | | | | | Differential revision: https://reviews.llvm.org/D27576 Reviewers: EricWF llvm-svn: 290889
* [libcxx] Fix testing of the externally-threaded library buildAsiri Rathnayake2017-01-031-3/+17
| | | | | | | | | | | | | | | | | | | | after r290850 Before r290850, building libcxx with -DLIBCXX_HAS_EXTERNAL_THREAD_API=ON had two uses: - Allow platform vendors to plug-in an __external_threading header which should take care of the entire threading infrastructure of libcxx - Allow testing of an externally-threaded library build; where the thread API is declared using pthread data structures, and the implementation of this API is provided as a separate library (test/support/external_threads.cpp) and linked-in when running the test suite. r290850 breaks the second use case (pthread data structures are no longer available). This patch re-stores the ability to build+test an externally-threaded library variant on a pthread based system. llvm-svn: 290878
* threading_support: refactor for Win32 threadingSaleem Abdulrasool2017-01-031-81/+113
| | | | | | | | | Refactor the header to allow us to implement alternate threading models with alternate data structures. Take the opportunity to clang-format the area. This will allow us to avoid re-declaring the interfaces for Win32 threading. NFC llvm-svn: 290850
* [libcxx] Improve the gcc workaround for the missing __has_include macro.Asiri Rathnayake2016-10-141-13/+11
| | | | | | NFC. llvm-svn: 284237
* [libcxx] Do not declare the thread api when __external_threading is presentAsiri Rathnayake2016-10-141-4/+5
| | | | | | | | | | | | | | | | This fixes a small omission where even when __external_threading is provided, we attempt to declare a pthread based threading API. Instead, we should leave out everything for the __external_threading header to take care of. The __threading_support header provides a proof-of-concept externally threaded libc++ variant when _LIBCPP_HAS_THREAD_API_EXTERNAL is defined. But if the __external_threading header is present, we should exclude all of that POC stuff. Reviewers: EricWF Differential revision: https://reviews.llvm.org/D25468 llvm-svn: 284232
* [libcxx] Fix gcc builds.Asiri Rathnayake2016-09-131-2/+13
| | | | | | | Step around a gcc pre-processor defect which causes it to fail to parse the __has_include macro check. llvm-svn: 281310
* [libcxx] Introduce an externally-threaded libc++ variant.Asiri Rathnayake2016-09-111-41/+72
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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
* [libcxx] Allow explicit pthread opt-inBen Craig2016-05-251-3/+3
| | | | | | | | | | | | | | | The existing pthread detection code in __config is pretty good for common operating systems. It doesn't allow cmake-time choices to be made for uncommon operating systems though. This change adds the LIBCXX_HAS_PTHREAD_API cmake flag, which turns into the _LIBCPP_HAS_THREAD_API_PTHREAD preprocessor define. This is a name change from the old _LIBCPP_THREAD_API_PTHREAD. The lit tests want __config_site.in variables to have a _LIBCPP_HAS prefix. http://reviews.llvm.org/D20573 llvm-svn: 270735
* Refactor pthread usage of libcxx.Asiri Rathnayake2016-05-061-0/+205
This patch extracts out all the pthread dependencies of libcxx into the new header __threading_support. The motivation is to make it easy to re-target libcxx into platforms that do not support pthread. Original patch from Fulvio Esposito (fulvio.esposito@outlook.com) - D11781 Applied with tweaks - D19412 Change-Id: I301111f0075de93dd8129416e06babc195aa936b llvm-svn: 268734
OpenPOWER on IntegriCloud