[PATCH 4/5] barrier: use int instead of unsigned char for the phase state
Thomas Rodgers
rodgert@appliantology.com
Mon Mar 1 17:40:23 GMT 2021
Botched replying to the list, sending again
On 2021-03-01 09:38, Thomas Rodgers wrote:
> On 2021-03-01 09:24, Thiago Macieira via Libstdc++ 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.
>
> If it's non-atomic, then how is wait() supposed to wait on it,
> atomically?
>
>> 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.
>
> And I am not disagreeing with that. I am, however saying, that I know
> this particular implementation (well the upstream one it is based on)
> has been extensively tested by the original author (ogiroux) including
> time on Summit. If we are going to start changing his design decisions
> (beyond the largely cosmetic, not algorithmic, ones that I have made as
> per Jonathan's request), they should be motivated by more than a 'well
> we feel int's would be better here because Futex' justification.
More information about the Libstdc++
mailing list