tech-userlevel archive

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

Re: PATCH libatomic

On 07.05.2020 22:45, Joerg Sonnenberger wrote:
> On Thu, May 07, 2020 at 10:13:30PM +0200, Kamil Rytarowski wrote:
>> On 07.05.2020 21:45, Joerg Sonnenberger wrote:
>>> On Thu, May 07, 2020 at 05:43:02AM +0200, Kamil Rytarowski wrote:
>>>> Lack of libatomic is increasingly hard to deal with. This library
>>>> implements function calls for atomic operations.
>>> I'm sure you have done the research on why the existing arguments
>>> against providing libatomic are wrong. For some reasons, you have missed
>>> including them in your email.
>> 1. Usually slower than cpu instructions as there are syscalls involved.
>> 2. Not safe for shared memory scenarios between multiple applications.
> So you haven't done the research on the arguments given last time. Just
> to save you the trouble, the immediate arguments without spending lots
> of mental time are:
> (1) They introduce non-trivial blocking conditions, often defeating the
> reason for using atomics in first place.
> (2) They don't work in a constrained environment and are broken by
> common UNIX primitives like memory mapped IO or shared memory.
> (3) They are not async signal safe.

libatomic is a workaround and delivers standard runtime feature that is
defined in C and C++ (and rust, ziglang, go and others) and none of the
above is a blocker in real software.

None of the above corner cases is a real world issue. If we would care
about them, we would forbid using many other standard features such as
floating point numbers... just because in corner cases they are not

>> Both are no issue in real life as otherwise NetBSD wouldn't be the
>> (almost?) only leftover without libatomic.
> All the world is Linux x64 and most people don't care about anything
> else. That's the core issue and not whether they are a bad design
> decision for portable software. Even then, I never objected to providing
> libatomic in pkgsrc and use it as low effort hackaround for broken
> software. I am strongly against anything in base depending on it though
> exactly because it is a lazy's person fix.

libatomic is mandatory for x86_64 linux as well, mostly for 16byte
atomic operations (although this is available in recent x86_64 CPUs).

libatomic (or equivalent feature) shall be a part the basesystem as the
NetBSD system provides C runtime.

>> Coincidentally futexes share the same arguments against multiprocess
>> operation.
> Coincidentally, the reason that implementing futexes is non-trivial is
> exactly because they target multiprocess operations. Try again, will
> you?
>>>> Personally I stopped testing sanitizers year ago as they required
>>>> libatomic. We want libatomic for LLDB in base. Rewritting everything to
>>>> stop using libatomic is no viable as this is a standard C11/C++14 feature.
>>> LLDB doesn't need libatomic. It needs a patch to fix the timer
>>> implementation to not require 64bit atomics. Which is exactly one of the
>>> original points that libatomic hides major performance issues and
>>> amusingly in this case, even in time sensitive code.
>> Same argument can be state about every application or test suite (LLVM
>> sanitizers not tested in almost 1 year?), that we can rewrite everything
>> which is futile process.
> Ah right, you have taken a short cut and therefore happy with the
> result. Proper design is a futile effort.

I'm fine to see a better libatomic design, but over the years (I see
discussions for like 5 years in NetBSD), nothing happened. libatomic in
llvm/gcc is what is good enough in real software on all non-constrained

> Joerg

Attachment: signature.asc
Description: OpenPGP digital signature

Home | Main Index | Thread Index | Old Index