tech-userlevel archive

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]

Re: PATCH libatomic



On 11.05.2020 16:19, Joerg Sonnenberger wrote:
> On Mon, May 11, 2020 at 11:38:28AM +0200, Kamil Rytarowski wrote:
>> On 11.05.2020 01:49, Joerg Sonnenberger wrote:
>>> On Mon, May 11, 2020 at 01:11:32AM +0200, Kamil Rytarowski wrote:
>>>> On 10.05.2020 18:38, Kamil Rytarowski wrote:
>>>>>  LLDB will be patched to avoid atomics.
>>>> I have checked LLDB and std::atomic<uint64_t> is used on purpose and was
>>>> switched from mutexes 3 years ago.
>>>>
>>>> https://github.com/llvm/llvm-project/commit/f9d16476573e16856bdb3250c817b0a2c631d2b1
>>>>
>>>> Reverting this (or rewriting) is not viable as this change improved the
>>>> performance, the code was changed meanwhile and there were added two
>>>> more associated std::atomic<> variables. LLDB also requires recent C++
>>>> runtime.
>>>
>>> Using 64bit atomics when they are present is fine. When are not
>>> available, it is a huge hidden cost. This problem was discussed on the
>>> LLDB mailing lists a while ago and there are essentially four possible
>>> approaches:
>>>
>>> (1) If there are no 64bit atomic ops, go back to using the explicit
>>> mutex. This makes the cost explicit at the very least.
>>
>> We agreed that the primary solution is to fallback to mutexes. This is
>> what is done by libatomic.
> 
> Who is we again this time? I certainly didn't agree to it.
> 
> Joerg
> 

Just reread "(1)" verbatim: "go back to explicit mutex". C11/C++14
atomics delivers semantically this with aid of libatomic.

Attachment: signature.asc
Description: OpenPGP digital signature



Home | Main Index | Thread Index | Old Index