On Mon, 30 Aug 2021 at 20:24, Thiago Macieira <thiago_at_[hidden]> wrote:
>
> On Monday, 30 August 2021 10:07:41 PDT Ville Voutilainen wrote:
> > Sure, but there's still a difference between "it's possible that it
> > just isn't small"
> > and "we know it's not small and can't be made small". :) The former is
> > indeed an impossible
> > thing for the standard to guarantee, but at least it allows, for some
> > platforms, perhaps
> > many, to avoid the problem of the latter, whereas rainy wishes of
> > ABI-breaking size shrinkage in std::mutex are not realistic.
>
> I understand. And I'll defer to your opinion: you're a maintainer in
> libstdc++, so this thing is likely to come to you and your co-maintainers
> there. If you're comfortable with the complexity, who am I to argue?
>
> Just note I do maintain such a thing (QMutex) and I am saying it's full of
> pitfalls to get it right.

It is indeed. We have run into many of them, because libstdc++ already
has this type implemented,
it's just doing the equivalents of calls to member function of an
atomic_mutex as different calls,
inside the guts of stop_token. Which is why I think it's fine to
standardize this type from an implementation
burden standpoint, because we have to suffer through that in stop_token anyway.

> Anyway, can I ask that we get a spinlock before we get a mutex? Before C++17
> it was impossible to get it right with std::atomic_flag; right, it's just non-
> obvious.

The marching order of an atomic_mutex and spinlock is completely
non-obvious to me, I happily don't program
at these levels much, so I'll also happily defer this to Marko. :)