On Thu, 2 Apr 2026 at 14:43, Frederick Virchanza Gotham via Std-Proposals <
std-proposals_at_[hidden]> wrote:

>
>
> On Thursday, April 2, 2026, Marcin Jaczewski <marcinjaczewski86_at_[hidden]>
> 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.