On Mon, 1 Mar 2021 at 20:09, Thiago Macieira via Libstdc++ <libstd...@gcc.gnu.org> wrote: > > On Sunday, 28 February 2021 07:05:47 PST Hans-Peter Nilsson wrote: > > On Fri, 26 Feb 2021, Thiago Macieira via Gcc-patches wrote: > > > ints can be used in futexes. chars can't. > > > > Shouldn't that be an atomic type instead of a bare int then? > > There are a couple of atomic_refs: > > using __atomic_phase_ref_t = std::__atomic_ref<__barrier_phase_t>; > using __atomic_phase_const_ref_t = std::__atomic_ref<const > __barrier_phase_t>; > > And _M_phase, despite being non-atomic, is never accessed without the > atomic_ref, aside from the constructor. Both arrive() and wait() start off by > creating the atomic_ref. > > But I confess I don't understand this code sufficiently to say it is correct. > I'm simply saying that waiting on unsigned chars will not use a futex, at > least until https://lkml.org/lkml/2019/12/4/1373 is merged into the kernel.
I do have a question about the intent/concern here, regardless of what your patch technically does. The ABI break _is_ your concern, and the "heisenbugs" you were worried about would in fact be caused by the ABI break? So if you embed these things in your QAtomicThing, the ABI break may mess it up(*)? Is that a correct understanding of the concern here? (*) And inlining might not help because users might compile a different std::atomic_thing in their program than what your DSO has been compiled with, and you may end up using mixtures.
