summaryrefslogtreecommitdiffstats
path: root/libcxx/include/thread
Commit message (Collapse)AuthorAgeFilesLines
* [libc++] Hide some functions and types in <future> and <thread> as hiddenLouis Dionne2019-12-101-0/+1
| | | | | Otherwise, weak symbols leak into user programs when using `async` with non-internal types.
* Rework recursive_timed_mutex so that it uses __thread_id instead of using ↵Marshall Clow2019-08-141-69/+5
| | | | | | the lower-level __libcpp_thread_id. This is prep for fixing PR42918. Reviewed as https://reviews.llvm.org/D65895 llvm-svn: 368867
* libcxx: Define __STDCPP_THREADS__ to 1, not to __cplusplus.Nico Weber2019-07-301-4/+0
| | | | | | | | | | | | | | | | | | | [cpp.predefined]p2: __STDCPP_THREADS__ Defined, and has the value integer literal 1, if and only if a program can have more than one thread of execution . Also define it only if it's not defined already, since it's supposed to be defined by the compiler. Also move it from thread to __config (which requires setting it only if _LIBCPP_HAS_NO_THREADS is not defined). Part of PR33230. The intent is to eventually make the compiler define this instead. llvm-svn: 367316
* Fix backwards test that I committed yesterday. SighMarshall Clow2019-04-031-2/+2
| | | | llvm-svn: 357540
* Special case some duration arithmetic for GCC and PPC because their long ↵Marshall Clow2019-04-021-0/+5
| | | | | | double constant folding is broken. Fixes PR#39696. llvm-svn: 357478
* 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
* [libc++] Make sure we can build libc++ with -fvisibility=hiddenLouis Dionne2018-10-251-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | Summary: When building with -fvisibility=hidden, some symbols do not get exported from libc++.dylib. This means that some entities are not explicitly given default visibility in the source code, and that we rely on the fact -fvisibility=default is the default. This commit explicitly gives default visibility to those symbols to avoid being dependent on the command line flags used. The commit also remove symbols from the dylib -- those symbols do not actually need to be exported from the dylib and this should not be an ABI break. Finally, in the future, we may want to mark the whole std:: namespace as having hidden visibility (to switch from opt-out to opt-in), in which case the changes done in this commit will be required. Reviewers: EricWF Subscribers: mgorny, christof, dexonsmith, libcxx-commits Differential Revision: https://reviews.llvm.org/D52662 llvm-svn: 345260
* Implement LWG 3039 and 3041 - 'Treating Unnecessary decay'.Marshall Clow2018-03-201-1/+1
| | | | llvm-svn: 328054
* [Libc++] Use #pragma push_macro/pop_macro to better handle min/max on WindowsEric Fiselier2017-05-311-0/+5
| | | | | | | | | | | | | | | | 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
* Cleanup _LIBCPP_HAS_NO_<c++11-feature> macros in thread.Eric Fiselier2017-04-181-23/+19
| | | | llvm-svn: 300622
* Implement P0599: 'noexcept for hash functions'. Fix a couple of hash ↵Marshall Clow2017-03-231-1/+1
| | | | | | functions (optional<T> and unique_ptr<T>) which were mistakenly marked as 'noexcept'. Reviewed as https://reviews.llvm.org/D31234 llvm-svn: 298573
* [libc++] Make _LIBCPP_TYPE_VIS export membersShoaib Meenai2017-03-021-1/+4
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: Most classes annotated with _LIBCPP_TYPE_VIS need to have at least some of their members exported, otherwise we have a lot of link errors when linking against a libc++ built with hidden visibility. This also makes _LIBCPP_TYPE_VIS be consistent across platforms, since on Windows it already exports members. With this change made, any template methods of a class marked _LIBCPP_TYPE_VIS will also get default visibility when instantiatied, which is not desirable for clients of libc++ headers who wish to control their visibility; this is the same issue as PR30642. Annotate all problematic methods with an explicit visibility specifier to avoid this. The problematic methods were found by running bad-visibility-finder [1] against the libc++ headers after making the _LIBCPP_TYPE_VIS change. The small methods were marked for inlining; the larger ones hidden. [1] https://github.com/smeenai/bad-visibility-finder Reviewers: mclow.lists, EricWF Subscribers: cfe-commits Differential Revision: https://reviews.llvm.org/D25208 llvm-svn: 296732
* Use protected name for the prototype arguments.Joerg Sonnenberger2017-02-091-1/+1
| | | | llvm-svn: 294585
* [libcxx] Don't assume __libcpp_thread_t is an integral typeAsiri Rathnayake2017-01-161-5/+5
| | | | | | | | | | | | | 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
* provide Win32 native threadingSaleem Abdulrasool2017-01-071-8/+7
| | | | | | | | | | | 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
* [NFC] Rename _LIBCPP_TYPE_VIS_ONLY to _LIBCPP_TEMPLATE_VISEric Fiselier2017-01-041-3/+3
| | | | | | | | | | | | | The name _LIBCPP_TYPE_VIS_ONLY is no longer accurate because both _LIBCPP_TYPE_VIS and _LIBCPP_TYPE_VIS_ONLY expand to __attribute__((__type_visibility__)) with Clang. The only remaining difference is that _LIBCPP_TYPE_VIS_ONLY can be applied to templates whereas _LIBCPP_TYPE_VIS cannot (due to dllimport/dllexport not being allowed on templates). This patch renames _LIBCPP_TYPE_VIS_ONLY to _LIBCPP_TEMPLATE_VIS. llvm-svn: 291035
* [libcxx] Introduce an externally-threaded libc++ variant.Asiri Rathnayake2016-09-111-4/+4
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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
* Fix PR30202 - notify_all_at_thread_exit seg faults if run from a raw pthread ↵Eric Fiselier2016-09-031-16/+7
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | context. Summary: This patch allows threads not created using `std::thread` to use `std::notify_all_at_thread_exit` by ensuring the TL state has been initialized within `std::notify_all_at_thread_exit`. Additionally this patch "fixes" a potential oddity in `__thread_local_pointer::reset(pointer)`, which would previously delete the old thread local data. However there should *never* be old thread local data because pthread *should* null it out on thread exit. Unfortunately it's possible that pthread failed to do this according to the spec: > > Upon key creation, the value NULL shall be associated with the new key in all active threads. Upon thread creation, the value NULL shall be associated with all defined keys in the new thread. > > An optional destructor function may be associated with each key value. At thread exit, if a key value has a non-NULL destructor pointer, and the thread has a non-NULL value associated with that key, the value of the key is set to NULL, and then the function pointed to is called with the previously associated value as its sole argument. The order of destructor calls is unspecified if more than one destructor exists for a thread when it exits. > > If, after all the destructors have been called for all non-NULL values with associated destructors, there are still some non-NULL values with associated destructors, then the process is repeated. If, after at least {PTHREAD_DESTRUCTOR_ITERATIONS} iterations of destructor calls for outstanding non-NULL values, there are still some non-NULL values with associated destructors, implementations may stop calling destructors, or they may continue calling destructors until no non-NULL values with associated destructors exist, even though this might result in an infinite loop. However if pthread fails to delete the value it is probably incorrect for us to do it. Destroying the value performs all of the "at thread exit" actions registered with it but we are way past "at thread exit". Reviewers: mclow.lists, bcraig, EricWF Subscribers: cfe-commits Differential Revision: https://reviews.llvm.org/D24159 llvm-svn: 280588
* Cleanup error handling when TLS creation failsEric Fiselier2016-05-301-3/+1
| | | | llvm-svn: 271235
* Refactor pthread usage of libcxx.Asiri Rathnayake2016-05-061-19/+20
| | | | | | | | | | | | | 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
* Fix most GCC attribute ignored warningsEric Fiselier2016-04-211-1/+1
| | | | llvm-svn: 267074
* [libcxx] Fix PR15638 - Only allocate in parent when starting a thread to ↵Eric Fiselier2016-04-201-17/+33
| | | | | | | | | | | | | | | | | | | | | prevent calling terminate. Summary: Hi, When creating a new thread libc++ performs at least 2 allocations. The first allocates a tuple of args and the functor that will be passed to the new thread. The second allocation is for the thread local storage needed internally by libc++. Currently the second allocation happens in the child thread, meaning that if it throws the program will terminate with an uncaught bad alloc. The solution to this is to allocate ALL memory in the parent thread and then pass it to the child. See https://llvm.org/bugs/show_bug.cgi?id=15638 Reviewers: mclow.lists, danalbert, jroelofs, EricWF Subscribers: cfe-commits Differential Revision: http://reviews.llvm.org/D13748 llvm-svn: 266851
* Cleanup: move visibility/linkage attributes to the first declaration.Evgeniy Stepanov2015-11-071-1/+2
| | | | | | | | | | | | This change moves visibility attributes from out-of-class method definitions to in-class declaration. This is needed for a switch to attribute((internal_linkage)) (see http://reviews.llvm.org/D13925) which can only appear on the first declaration. This change does not touch istream/ostream/streambuf. They are handled separately in http://reviews.llvm.org/D14409. llvm-svn: 252385
* Fix use of static_assert macro with nested commasEric Fiselier2015-08-191-1/+1
| | | | llvm-svn: 245410
* [libc++] Fix PR22606 - Leak pthread_key with static storage duration to ↵Eric Fiselier2015-08-181-22/+31
| | | | | | | | | | | | | | | | | | | | | | ensure all of thread-local destructors are called. Summary: See https://llvm.org/bugs/show_bug.cgi?id=22606 for more discussion. Most of the changes in this patch are file reorganization to help ensure assumptions about how __thread_specific_pointer is used hold. The assumptions are: * `__thread_specific_ptr<Tp>` is only created with a `__thread_struct` pointer. * `__thread_specific_ptr<Tp>` can only be constructed inside the `__thread_local_data()` function. I'll remove the comments before committing. They are there for clarity during review. Reviewers: earthdok, mclow.lists Subscribers: cfe-commits Differential Revision: http://reviews.llvm.org/D8802 llvm-svn: 245334
* Explicitly include <sched.h> for sched_yield()Sergey Dmitrouk2014-12-081-0/+1
| | | | | | | | It might be implicitly included by <pthread.h> (and that's why it worked so far), but it's not guaranteed (for example, this is not the case with newlib). llvm-svn: 223661
* Allow libc++ to be built on systems without POSIX threadsJonathan Roelofs2014-09-051-0/+6
| | | | | | | | | | If you're crazy enough to want this sort of thing, then add -D_LIBCPP_HAS_NO_THREADS to your CXXFLAGS and --param=additiona_features=libcpp-has-no-threads to your lit commnad line. http://reviews.llvm.org/D3969 llvm-svn: 217271
* Nico Rieck: this patch series fixes visibility issues on Windows as ↵Howard Hinnant2013-08-121-8/+7
| | | | | | explained in <http://lists.cs.uiuc.edu/pipermail/cfe-dev/2013-August/031214.html>. llvm-svn: 188192
* Fix stupid but harmless type-o. Fixes ↵Howard Hinnant2013-04-031-2/+2
| | | | | | http://llvm.org/bugs/show_bug.cgi?id=15657. llvm-svn: 178691
* Add missing #ifndef _LIBCPP_NO_EXCEPTIONS around throw in include/thread.Howard Hinnant2013-03-281-0/+2
| | | | llvm-svn: 178237
* No functionality change at this time. I've split _LIBCPP_VISIBLE up into ↵Howard Hinnant2013-03-061-9/+9
| | | | | | two flags: _LIBCPP_TYPE_VIS and _LIBCPP_FUNC_VIS. This is in preparation for taking advantage of clang's new __type_visibility__ attribute. llvm-svn: 176593
* Dimitry Andric: many visibility fixes. Howard: Much appreciated. Can you ↵Howard Hinnant2012-09-141-3/+3
| | | | | | send me a patch to CREDITS.TXT? llvm-svn: 163862
* Change sleep_for, sleep_until, and the condition_variable timed waitHoward Hinnant2012-08-301-4/+14
| | | | | | | | | | | | | functions to protect against duration and time_point overflow. Since we're about to wait anyway, we can afford to spend a few more cycles on this checking. I purposefully did not treat the timed try_locks with overflow checking. This fixes http://llvm.org/bugs/show_bug.cgi?id=13721 . I'm unsure if the standard needs clarification in this area, or if this is simply QOI. The <chrono> facilities were never intended to overflow check, but just to not overflow if durations stayed within +/- 292 years. llvm-svn: 162925
* Patch contributed by Dev Dude for mingw64 port.Howard Hinnant2012-08-191-1/+1
| | | | llvm-svn: 162188
* noexcept applied to <thread>.Howard Hinnant2012-07-211-37/+37
| | | | llvm-svn: 160606
* Starting using murmur2 when combining multiple size_t's into a single hash, ↵Howard Hinnant2011-12-051-4/+5
| | | | | | and also for basic_string. Also made hash<thread::id> ever so slighly more portable. I had to tweak one test which is questionable (definitely not portable) anyway. llvm-svn: 145795
* Further macro protection by replacing _[A-Z] with _[A-Z]pHoward Hinnant2011-11-291-20/+20
| | | | llvm-svn: 145410
* de-tabbifyHoward Hinnant2011-10-171-11/+11
| | | | llvm-svn: 142237
* Windows support by Ruben Van Boxem.Howard Hinnant2011-10-171-0/+2
| | | | llvm-svn: 142235
* _STD -> _VSTD to avoid macro clash on windowsHoward Hinnant2011-06-301-4/+4
| | | | llvm-svn: 134190
* I had a giant misunderstanding of what 'synchronizes with' meant in ↵Howard Hinnant2011-05-191-1/+1
| | | | | | [futures.async]/p5. This invalidated the current design of async in <future>. This is a new design, based on my new understanding, which has been confirmed on the lwg mailing list. The summary is that ~future() (and ~shared_future()) will block when they are created from within async, and the thread hasn't finished yet. As part of this work I created two new type traits: __invokable<F, Args...>::value and __invoke_of<F, Args...>::type. These are what result_of<F(Args...)> wanted to be when it grew up, but never will be. __invoke_of is carefully crafted so that it can serve as its own enable_if (type doesn't exist if the signature isn't invokable). All of this work is C++11 only. llvm-svn: 131639
* Brought thread variadic constructor up to current spec, which allows ↵Howard Hinnant2011-05-161-6/+28
| | | | | | move-only functors and move-only arguments, but disallows functors with non-const lvalue reference parameters. llvm-svn: 131413
* Effort to reduce the number of exported symbolsHoward Hinnant2010-12-171-1/+1
| | | | llvm-svn: 122057
* N3191: C++ Timeout SpecificationHoward Hinnant2010-11-201-2/+2
| | | | llvm-svn: 119909
* license changeHoward Hinnant2010-11-161-2/+2
| | | | llvm-svn: 119395
* I have reverted all contributions made by Jesse Towner in revision 110724Howard Hinnant2010-11-161-5/+0
| | | | llvm-svn: 119383
* Convert __thread_local_data to the singleton patternHoward Hinnant2010-10-141-2/+2
| | | | llvm-svn: 116500
* visibility-decoration.Howard Hinnant2010-09-231-15/+34
| | | | llvm-svn: 114671
* Changed __config to react to all of clang's currently documented has_feature ↵Howard Hinnant2010-09-041-4/+4
| | | | | | flags, and renamed _LIBCPP_MOVE to _LIBCPP_HAS_NO_RVALUE_REFERENCES to be more consistent with the rest of the libc++'s flags, and with clang's nomenclature. llvm-svn: 113086
* [futures.atomic_future] and notify_all_at_thread_exit. This completes the ↵Howard Hinnant2010-09-031-0/+1
| | | | | | header <future> and all of Chapter 30 (for C++0x enabled compilers). llvm-svn: 113017
OpenPOWER on IntegriCloud