14 Commits

Author SHA1 Message Date
Nikolas Klauser
4748b494e1
[libc++] Mark a few functions in the dylib as noexcept (#94098)
This avoids generating landing pads in some of the `atomic` functions
that will never be used, since these functions never throw exceptions.
2024-06-11 22:18:51 -04:00
Louis Dionne
04f01a2b9c
[libc++] Make the __availability header a sub-header of __config (#93083)
In essence, this header has always been related to configuration of
the library but we didn't want to put it inside <__config> due to
complexity reasons. Now that we have sub-headers in <__config>, we
can move <__availability> to it and stop including it everywhere since
we already obtain the required macros via <__config>.
2024-05-28 18:29:11 -07:00
Damien L-G
42ba740aff
[libc++] Implement C++20 atomic_ref (#76647)
Implement the std::atomic_ref class template by reusing atomic_base_impl.
Based on the work from https://reviews.llvm.org/D72240
2024-05-21 15:54:08 -07:00
Hui
1f613bce19
[libc++] refactor cxx_atomic_wait to make it reusable for atomic_ref (#81427)
The goal of this patch is to make `atomic`'s wait functions to be
reusable by `atomic_ref`.
https://github.com/llvm/llvm-project/pull/76647

First, this patch is built on top of
https://github.com/llvm/llvm-project/pull/80596 , to reduce the future
merge conflicts.

This patch made the following functions as "API"s to be used by
`atomic`, `atomic_flag`, `semaphore`, `latch`, `atomic_ref`

```
__atomic_wait
__atomic_wait_unless
__atomic_notify_one
__atomic_notify_all
```

These functions are made generic to support `atomic` type and
`atomic_ref`. There are two customisation points.

```
// How to load the value from the given type (with a memory order)
__atomic_load
```


```
// what is the contention address that the platform `wait` function is going to monitor
__atomic_contention_address
```


For `atomic_ref` (not implemented in this patch), the `load` and
`address` function will be different, because
- it does not use the "atomic abstraction layer" so the `load` operation
will be some gcc builtin
- the contention address will be the user's actual type that the
`atomic_ref` is pointing to
2024-03-02 14:50:52 +00:00
Hui
1a0c988ebd [libc++][NFC] rename variable in atomic_sync
As discussed in https://github.com/llvm/llvm-project/pull/81427/files#r1509266817
rename the variable as a separate commit
2024-03-01 19:52:14 +00:00
Jan Kokemüller
95ebf2be0e
[libc++] Refactor the predicate taking variant of __cxx_atomic_wait (#80596)
This is a follow-up PR to
<https://github.com/llvm/llvm-project/pull/79265>. It aims to be a
gentle refactoring of the `__cxx_atomic_wait` function that takes a
predicate.

The key idea here is that this function's signature is changed to look
like this (`std::function` used just for clarity):

```c++
__cxx_atomic_wait_fn(Atp*, std::function<bool(Tp &)> poll, memory_order __order);
```

...where `Tp` is the corresponding `value_type` to the atomic variable
type `Atp`. The function's semantics are similar to `atomic`s `.wait()`,
but instead of having a hardcoded predicate (is the loaded value unequal
to `old`?) the predicate is specified explicitly.

The `poll` function may change its argument, and it is very important
that if it returns `false`, it leaves its current understanding of the
atomic's value in the argument. Internally, `__cxx_atomic_wait_fn`
dispatches to two waiting mechanisms, depending on the type of the
atomic variable:

1. If the atomic variable can be waited on directly (for example,
Linux's futex mechanism only supports waiting on 32 bit long variables),
the value of the atomic variable (which `poll` made its decision on) is
then given to the underlying system wait function (e.g. futex).
2. If the atomic variable can not be waited on directly, there is a
global pool of atomics that are used for this task. The ["eventcount"
pattern](<https://gist.github.com/mratsim/04a29bdd98d6295acda4d0677c4d0041>)
is employed to make this possible.

The eventcount pattern needs a "monitor" variable which is read before
the condition is checked another time. libcxx has the
`__libcpp_atomic_monitor` function for this. However, this function only
has to be called in case "2", i.e. when the eventcount is actually used.
In case "1", the futex is used directly, so the monitor must be the
value of the atomic variable that the `poll` function made its decision
on to continue blocking. Previously, `__libcpp_atomic_monitor` was
_also_ used in case "1". This was the source of the ABA style bug that
PR#79265 fixed.

However, the solution in PR#79265 has some disadvantages:

- It exposes internals such as `cxx_contention_t` or the fact that
`__libcpp_thread_poll_with_backoff` needs two functions to higher level
constructs such as `semaphore`.
- It doesn't prevent consumers calling `__cxx_atomic_wait` in an error
prone way, i.e. by providing to it a predicate that doesn't take an
argument. This makes ABA style issues more likely to appear.

Now, `__cxx_atomic_wait_fn` takes just _one_ function, which is then
transformed into the `poll` and `backoff` callables needed by
`__libcpp_thread_poll_with_backoff`.

Aside from the `__cxx_atomic_wait` changes, the only other change is the
weakening of the initial atomic load of `semaphore`'s `try_acquire` into
`memory_order_relaxed` and the CAS inside the loop is changed from
`strong` to `weak`. Both weakenings should be fine, since the CAS is
called in a loop, and the "acquire" semantics of `try_acquire` come from
the CAS, not from the initial load.
2024-02-19 14:28:51 +00:00
Hui
825658856d
[libc++] fix counting_semaphore lost wakeups (#79265)
Fixes #77659
Fixes #46357

Picked up from https://reviews.llvm.org/D114119
2024-02-05 13:59:48 +00:00
Louis Dionne
7162fd750e
[libc++] Split the monolithic __threading_support header (#79654)
The <__threading_support> header is a huge beast and it's really
difficult to navigate. I find myself struggling to find what I want
every time I have to open it, and I've been considering splitting it up
for years for that reason.

This patch aims not to contain any functional change. The various
implementations of the threading base are simply moved to separate
headers and then the individual headers are simplified in mechanical
ways. For example, we used to have redundant declarations of all the
functions at the top of `__threading_support`, and those are removed
since they are not needed anymore. The various #ifdefs are also
simplified and removed when they become unnecessary.

Finally, this patch adds documentation for the API we expect from any
threading implementation.
2024-01-30 08:35:15 -05:00
Louis Dionne
9783f28cbb
[libc++] Format the code base (#74334)
This patch runs clang-format on all of libcxx/include and libcxx/src, in
accordance with the RFC discussed at [1]. Follow-up patches will format
the benchmarks, the test suite and remaining parts of the code. I'm
splitting this one into its own patch so the diff is a bit easier to
review.

This patch was generated with:

   find libcxx/include libcxx/src -type f \
      | grep -v 'module.modulemap.in' \
      | grep -v 'CMakeLists.txt' \
      | grep -v 'README.txt' \
      | grep -v 'libcxx.imp' \
      | grep -v '__config_site.in' \
      | xargs clang-format -i

A Git merge driver is available in libcxx/utils/clang-format-merge-driver.sh
to help resolve merge and rebase issues across these formatting changes.

[1]: https://discourse.llvm.org/t/rfc-clang-formatting-all-of-libc-once-and-for-all
2023-12-18 14:01:33 -05:00
Nikolas Klauser
173476ea04 [libc++] Add __decay_t and use it instead of decay<>::type
This avoids instantiating lots of types.

Reviewed By: ldionne, #libc

Spies: libcxx-commits

Differential Revision: https://reviews.llvm.org/D146984
2023-03-31 02:22:48 +02:00
Nikolas Klauser
4668dd8c4a [libc++] Run clang-tidy in all configurations that are run in the Docker container
Reviewed By: ldionne, Mordante, #libc

Spies: libcxx-commits, arichardson

Differential Revision: https://reviews.llvm.org/D143333
2023-02-28 19:14:58 +01:00
Mark de Wever
f41f392520 [libc++] Fixes operator& hijacking atomic types.
This uses std::addressof everywherein atomic. This is not strictly
needed for the integral and floating point specializations. They should
not be used by user defined types. But it's easier to fix everything.

Note these changes are made using a WIP clang-tidy plugin.

Reviewed By: #libc, ldionne

Differential Revision: https://reviews.llvm.org/D144786
2023-02-27 19:23:13 +01:00
Nikolas Klauser
ef3a3b0726 [libc++][NFC] Replace _VSTD and _LIBCPP_INLINE_VISIBILITY in <__atomic/*>
Reviewed By: Mordante, #libc

Spies: libcxx-commits

Differential Revision: https://reviews.llvm.org/D144258
2023-02-17 21:54:07 +01:00
Nikolas Klauser
46db8d822e [libc++] Granularize <atomic>
Reviewed By: Mordante, #libc

Spies: arichardson, libcxx-commits, krytarowski

Differential Revision: https://reviews.llvm.org/D142972
2023-02-17 12:44:32 +01:00