summaryrefslogtreecommitdiff
path: root/libcxx/src/shared_mutex.cpp
AgeCommit message (Collapse)Author
2025-05-28Revert "[libc++] Introduce ABI sensitive areas to avoid requiring ↵James Y Knight
_LIBCPP_HIDE_FROM_ABI everywhere (#131156)" (#141756) This reverts commit c861fe8a71e64f3d2108c58147e7375cd9314521. Unfortunately, this use of hidden visibility attributes causes user-defined specializations of standard-library types to also be marked hidden by default, which is incorrect. See discussion thread on #131156. ...and also reverts the follow-up commits: Revert "[libc++] Add explicit ABI annotations to functions from the block runtime declared in <__functional/function.h> (#140592)" This reverts commit 3e4c9dc299c35155934688184319d391b298fff7. Revert "[libc++] Make ABI annotations explicit for windows-specific code (#140507)" This reverts commit f73287e623a6c2e4a3485832bc3e10860cd26eb5. Revert "[libc++][NFC] Replace a few "namespace std" with the correct macro (#140510)" This reverts commit 1d411f27c769a32cb22ce50b9dc4421e34fd40dd.
2025-05-18[libc++] Introduce ABI sensitive areas to avoid requiring ↵Nikolas Klauser
_LIBCPP_HIDE_FROM_ABI everywhere (#131156) This patch introduces `_LIBCPP_{BEGIN,END}_EXPLICIT_ABI_ANNOTATIONS`, which allow us to have implicit annotations for most functions, and just where it's not "hide_from_abi everything" we add explicit annotations. This allows us to drop the `_LIBCPP_HIDE_FROM_ABI` macro from most functions in libc++.
2025-01-13[libcxx] Don't hold the lock when calling notify_* on gates in ↵Brotcrunsher
std::shared_mutex (#107876) Holding the associated lock while calling notify_* on a condition_variable is generally considered a pessimization, as the notified thread might "instantly" wake up, notice that it can't acquire the lock, and then goes back to sleep.
2023-11-05[libc++] Handle threads-related .cpp files like we do all other source files ↵Louis Dionne
(#71100) Source files in libc++ are added to the CMake targets only if they are required by the configuration. We do this pretty consistently for all configurations like no-filesystem, no-random-device, etc. but we didn't do it for no-threads. This patch makes this consistent for no-threads, which is helpful in reducing the amount of work required to port libc++ to some platforms without threads. Indeed, with the previous approach, several threads-related source files would end up including headers that might fail to compile properly on some platforms. This issue is sidestepped entirely by making the approach for no-threads consistent with the other configurations.
2023-07-04[libc++][NFC] clang-format <shared_mutex>Louis Dionne
I am about to touch several lines in that file for a patch anyway, so I might as well clang-format it upfront to avoid mixing styles after my patch.
2023-03-22[libc++] Granularize __mutex_baseNikolas Klauser
This also updates the moved code to the current style. (i.e. `_VSTD` -> `std`, `_LIBCPP_INLINE_VISIBILITY` -> `_LIBCPP_HIDE_FROM_ABI`, clang-format). Reviewed By: Mordante, #libc, EricWF Spies: arichardson, libcxx-commits, mikhail.ramalho Differential Revision: https://reviews.llvm.org/D146228
2022-09-02[libc++] Make the naming of private member variables consistent and enforce ↵Nikolas Klauser
it through readability-identifier-naming Reviewed By: ldionne, #libc Spies: aheejin, sstefan1, libcxx-commits Differential Revision: https://reviews.llvm.org/D129386
2022-02-15[libc++] Replace `#include ""` with `<>` in libcxx/src/. NFCI.Arthur O'Dwyer
Our best guess is that the two syntaxes should have exactly equivalent effects, so, let's be consistent with what we do in libcxx/include/. I've left `#include "include/x.h"` and `#include "../y.h"` alone because I'm less sure that they're interchangeable, and they aren't inconsistent with libcxx/include/ because libcxx/include/ never does that kind of thing. Also, use the `_LIBCPP_PUSH_MACROS/POP_MACROS` dance for `<__undef_macros>`, even though it's technically unnecessary in a standalone .cpp file, just so we have consistently one way to do it. Differential Revision: https://reviews.llvm.org/D119561
2021-11-17[runtimes][NFC] Remove filenames at the top of the license noticeLouis Dionne
We've stopped doing it in libc++ for a while now because these names would end up rotting as we move things around and copy/paste stuff. This cleans up all the existing files so as to stop the spreading as people copy-paste headers around.
2019-12-02[libcxx{,abi}] Emit deplibs only when detected by CMakeMichał Górny
This is a followup to 35bc5276ca3. It fixes the dependent libs usage in libcxx and libcxxabi to link pthread and rt libraries only if CMake detects them, rather than based on explicit platform blacklist. Differential Revision: https://reviews.llvm.org/D70888
2019-07-22[runtimes] Don't depend on libpthread on AndroidYi Kong
r362048 added support for ELF dependent libraries, but broke Android build since Android does not have libpthread. Remove the dependency on the Android build. Differential Revision: https://reviews.llvm.org/D65098 llvm-svn: 366734
2019-05-30[runtimes] Check if pragma comment(lib, ...) is supported firstPetr Hosek
This fixes the issue introduced by r362048 where we always use pragma comment(lib, ...) for dependent libraries when the compiler is Clang, but older Clang versions don't support this pragma so we need to check first if it's supported before using it. llvm-svn: 362055
2019-05-30[runtimes] Support ELF dependent libraries featurePetr Hosek
As of r360984, LLD supports dependent libraries feature for ELF. libunwind, libc++abi and libc++ have library dependencies: libdl librt and libpthread, which means that when libunwind and libc++ are being statically linked (using -static-libstdc++ flag), user has to manually specify -ldl -lpthread which is onerous. This change includes the lib pragma to specify the library dependencies directly in the source that uses those libraries. This doesn't make any difference when using linkers that don't support dependent libraries. However, when using LLD that has dependent libraries feature, users no longer have to manually specifying library dependencies when using static linking, linker will pick the library automatically. Differential Revision: https://reviews.llvm.org/D62090 llvm-svn: 362048
2019-01-19Update more file headers across all of the LLVM projects in the monorepoChandler Carruth
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
2018-08-01[libc++] Remove _LIBCPP_BUILDING_XXX macros, which are redundant since ↵Louis Dionne
_LIBCPP_BUILDING_LIBRARY Summary: As suggested by Marshall in https://reviews.llvm.org/D49914 Reviewers: mclow.lists, EricWF Subscribers: christof, dexonsmith, cfe-commits Differential Revision: https://reviews.llvm.org/D50008 llvm-svn: 338475
2015-06-30Implement N4508: shared_mutex. Reviewed as http://reviews.llvm.org/D10480Marshall Clow
llvm-svn: 241067
2014-09-05Allow libc++ to be built on systems without POSIX threadsJonathan Roelofs
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
2014-03-17Implement N3891: A proposal to rename shared_mutex to shared_timed_mutexDavid Majnemer
This is as straightforward as it sounds, a renamed from shared_mutex to shared_timed_mutex. Note that libcxx .dylib and .so files built with c++14 support need to be rebuilt. llvm-svn: 204078
2013-09-21N3659: Shared locking in C++ Revision 2, c++1y onlyHoward Hinnant
llvm-svn: 191127