4 ms·
There are rw lock implementations where waiters (whether or readers or writers) don't contend on a shared cache line (they only touch it once to enqueue themsel
by nly 8mo ago
There are rw lock implementations where waiters (whether or readers or writers) don't contend on a shared cache line (they only touch it once to enqueue themselves, not to spin/wait)
These are usually called "scaleable locks" and the algorithms for them have been out there for decades. They are optimal from a cache coherence point of view.
The issue with them is it's impossible to support the same API as you're used to with std::shared_mutex, as every thread needs it's own line.
- gpderetta 8mo ago> it's impossible to support the same API as you're used to with std::shared_mutex If I understand the problem correctly, the standard library could specialize the scoped lock objects for the shared mutex, online allocate the waiter object in the lock (so it will be in the stack) and use an internal dedicated API. It might be harder (but not impossible) to interoperate threads using direct lock calls with threads using the scoped API. In any case it is a moot point, as I don't think any std library does it nor will never do as it would probably be ABI breaking.
- nly 8mo agoYes, The RAII lock_guard pattern is the correct and proper one. But efficient FIFO/scalable locks can't be created using the C POSIX locking API.