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.