C++ Logo


Advanced search

Re: Slim mutexes and locks based on C++20 std::atomic::wait

From: Thiago Macieira <thiago_at_[hidden]>
Date: Mon, 30 Aug 2021 10:24:02 -0700
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.

And we will get feature creep that doesn't exist in QMutex. QMutex is part of
Qt, so it isn't common in high-performance applications running on server
products. This slim mutex, on the other hand, is a good candidate for that, so
it may need to support transactional memory too.

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-

Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
   Software Architect - Intel DPG Cloud Engineering

Received on 2021-08-30 12:24:09