[libcxx-dev] A proposed approach to std::atomic_wait for libcxx

Louis Dionne via libcxx-dev libcxx-dev at lists.llvm.org
Thu Jun 20 12:52:51 PDT 2019

> On May 28, 2019, at 18:54, Olivier Giroux via libcxx-dev <libcxx-dev at lists.llvm.org> wrote:
> Hi everyone,
> To start the discussion of how libcxx should go about implementing this feature, I’ve prepared a cross-platform implementation of atomic_wait/atomic_notify_* for Mac/Linux/Windows/CUDA/unidentified-platform. I don’t claim that it’s fully tuned for your platform, nor do I claim that it’s perfect for every possible use, but it should not be terribly bad for any use either. It has various knobs to turn paths On/Off, so you can choose a different path on each platform, so long as it’s supported at all on that platform.
> You can find the implementation here: https://github.com/ogiroux/atomic_wait/ <https://github.com/ogiroux/atomic_wait/>.
> It has these strategies implemented:
> * Contention table. Used to optimize futex notify, or to hold CVs. Disable with __NO_TABLE.
> * Futex. Supported on Linux and Windows. For performance requires a table on Linux. Disable with __NO_FUTEX.
> * Condition variables. Supported on Linux and Mac. Requires table to function. Disable with __NO_CONDVAR.
> * Timed back-off. Supported on everything. Disable with __NO_SLEEP.
> * Spinlock. Supported on everything. Force with __NO_IDENT. Note: performance is too terrible to use.
> The strategy is chosen this way, by platform:
> * Linux: default to futex (with table), fallback to futex (no table) -> CVs -> timed backoff -> spin.
> * Mac: default to CVs (table), fallback to timed backoff -> spin.
> * Windows: default to futex (no table), fallback to timed backoff -> spin.
> * CUDA: default to timed backoff, fallback to spin. (This is not all checked in in this tree.)
> * Unidentified platform: default to spin.
> The unidentified platform support could be better. For instance, we should probably assume that <thread> is implemented and use the sleeping/yielding facilities there. It should not fall all the way back to __NO_IDENT, it should instead fall back to about where CUDA is expected to be.
> One of the main discussion points I’d like to drive with this, is the design of the contention management table, to go along the sharded lock table that backs __atomic_* and __c11_atomic_* built-ins. Ideally this would be handled the same way, meaning that it should live in libatomic.a or your substitute, and be shared with other C++ standard libraries on your platform.

Just for the record, I gave some feedback to Olivier offline. The main thing we agreed on was that we can implement the contention table inside compiler-rt and provide function declarations in the headers that allow libc++ to get access to the associated functions (e.g. __cxx_atomic_notify_all). We wouldn't add builtins to Clang yet until we actually have a need for them.


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/libcxx-dev/attachments/20190620/f409e75e/attachment.html>

More information about the libcxx-dev mailing list