On Thursday, April 2, 2026, Marcin Jaczewski <marcinjaczewski86@gmail.com> wrote:
> Don't you mean:
>
> std::big_int
>
> and:
>
> std::atomic< std::big_int >
>
> The latter could be specialised and optimised (instead of just allowing the compiler to use a mutex).
No, atomicity of counter that is shared has nothing with atomicy of
object itself that is not shared.
I'm writing this here on my phone, and at some point I'll have to sit down properly at a computer and think this through more, but if you're going to allow one thread to increment the reference of an object that's used by another thread, then it stands to reason that the referred object must be atomic too.
What I'm saying is that "big_int" would not use any atomics or locks. However "atomic< big_int >" would use a mutex for editing the very big number, and an atomic int for the reference counter.
This of course would mean that you can't use "atomic_ref" with a "big_int", because the atomic form of "big_int" would include a mutex. And please don't suggest the 'pthread' strategy of using a global container of mutexes.
To be clear, I'm not really interested in std::atomic<std::bit_int>, and std::atomic normally only works with trivially copyable types. Given that std::big_int has value semantics, it would be very confusing to make only the container atomic. At best, it would be done in a follow-up proposal.
The non-atomic std::big_int would still need to mutate the reference counter atomically so that the copy constructor is thread-safe.