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