On Fri, 20 Aug 2021 at 08:46, Marko Mäkelä via Std-Proposals
<std-proposals_at_[hidden]> wrote:
>
> Hi all,
>
> For a database kernel, I needed a small mutex or rw-lock with minimal
> features: no tracking of ownership, no reentrancy a.k.a. recursion for
> the basic variant. The small size of the object (32 or 64 bits) allows
> millions of the simplest mutex or rw-lock to be instantiated. One use
> case is that a hash array contains a lock and a number of pointers in a
> single cache line, such that the lock will protect the data that is
> stored in that cache line.
>
> I created a GitHub repository to demonstrate this:
>
> https://github.com/dr-m/atomic_sync
>
> I believe that the code works wherever std::atomic::wait() is available
> (currently, this includes MSVC on Windows, GCC or Clang on Linux with
> libstdc++-11). There is also a fallback implementation for C++11, using
> futex system calls on Linux or OpenBSD.
>
> I believe that it would be useful if the C++ standard library included
> mutex or rw-lock primitives that build upon std::atomic. I would
> appreciate feedback and advice how this could be converted into a formal
> proposal for inclusion in the standard.

Sounds like a great proposal to me; one decent way to write the
proposal is to copycat
an existing one from http://open-std.org/JTC1/SC22/WG21/docs/papers/2021/.
You're on the right track already, because a proposal needs to have
1) Rationale
2) Rationale
3) Rationale
4) Implementation experience
5) The actual technical specification, i.e. standardese, the wording.

I can help you further with it in any way you like, we can communicate
in our native language too, offline, if you prefer.
Anyway, creating a html proposal paper that has the rationale and
other explanation of what is proposed and why
is probably not too difficult, also adding a link to and explanation
of the implementation you already have. The wording
is its own ballgame, I can help you write that.

> Similar C++11 code is "in production" already. On Microsoft Windows,
> that implementation deviates from the above by using SRWLOCK,
> WaitOnAddress() and WakeByAddressSingle().

Right, and stdlib implementations use something like this elsewhere
too, like in the implementation of stop_token,
because mutexes are Too Heavy. :P


> Native mutexes or rw-locks tend to have huge storage requirements
> (sizeof(pthread_mutex_t)==48 on 64-bit GNU/Linux) and may have
> unsuitable semantics: When a lock is acquired by Thread A and ownership
> is passed an unspecified thread (for example, one that will be invoked
> on asynchronous I/O completion), we would want a subsequent acquisition
> by Thread A to block until the lock has been released (by some other
> thread). In pthread_mutex_t, PTHREAD_RECURSIVE_MUTEX_INITIALIZER_NP can
> be used to enable recursion, but there does not appear to be a portable
> way to disable it.

Right, and trying to make an existing std::mutex smaller might be a
tad difficult due to ABI breakage,
and making it smaller by removing capabilities from it wouldn't work
because it can be used as an interoperability
type.

I am, Yours Most Sincerely,
Ville Voutilainen
The Head of Delegation for Finland in the C++ Standards Committee