As std::big_int has value semantics and shared ownership I would expect the (absolute) value to be constant.   Therefore a 'mutex for editing' is not needed.   -----Ursprüngliche Nachricht----- Von:Frederick Virchanza Gotham via Std-Proposals <std-proposals_at_[hidden]> Gesendet:Do 02.04.2026 14:43 Betreff:Re: [std-proposals] std::big_int An:std-proposals <std-proposals_at_[hidden]>; CC:Frederick Virchanza Gotham <cauldwell.thomas_at_[hidden]>; On Thursday, April 2, 2026, Marcin Jaczewski <marcinjaczewski86_at_[hidden] <mailto: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. -- Std-Proposals mailing list Std-Proposals_at_[hidden] https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals