tech-userlevel archive

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

Re: PATCH libatomic

On 08.05.2020 14:44, Martin Husemann wrote:
> On Fri, May 08, 2020 at 02:26:45PM +0200, Kamil Rytarowski wrote:
>> With _Atomic() we can mark any arbitrary struct to have serialized
>> accesses. As I said, with your attitude we shall remove FPU support (and
>> softfloat) as they are not async safe, not safe in virtualization for
>> MMU accesses and more just to mention 2 issues.
> Now come on, that certainly is apples and oranges.

They are relatively comparable. Softfloat is like libatomic with similar
constraints. Softfloat shares similar problems to libatomic (like being
so slow that the purpose might be gone). Standard C calls like setjmp(3)
or longjmp(3) can mess the state of FPU, standard C signal handlers can
mess non-lock-free atomics.

We can redesign algorithms and avoid using atomics same as we can avoid
using floats.

> Joerg already agreed to have a "working" libatomic in pkgsrc, so all the
> lazy programmers can use them and 3rd party apps will be happy.
> Why do you insist on importing it in base?

libatomic is an integral part of the toolchain and shall match GCC and
Clang from base. There is ABI dependency, although the runtime library
does not change often, we are supposed to keep a few years of support of
a NetBSD host (and its toolchain). The library is implemented as a thin
library in GCC and LLVM. We provide C11 (/usr/bin/c11) in basesystem. If
we ignore C11 base, then we promise to deliver C++11.

Atomics support is not a feature for lazy programmers, it is rather the
opposite. Designing lock-free algorithms (with a fallback to locking
ones in libatomic) is extra mental work.

I generally agree that they can be misused, but the same argument can be
applied to many other standard features. I also agree that there are
corner cases when they fail, but again the same applies to other C features.

I also agree that when we use libatomic (same as softfloat) the purpose
o this feature might be gone in a performance critical software.

Promptly designed software can detect atomic features in either compile
tiem or runtime and act accordingly (abort, warn, permit, fallback to
different algorithm). In many cases libatomics usage is good enough
(same as softfloat).

I object to opinions that libatomic is generally broken, if that would
be the cause, it wouldn't be available and used on relatively all
relevant generic purpose Operating Systems. Personally, I already
received last year a feedback from one 3rd party project from Microsoft
that they prefer to drop NetBSD support (out of Windows, Linux, MacOS,
BSDs) rather than allow non-libatomic usage.

If we allow libatomic in pkgsrc only, then we need to deliver possibly 2
versions (gcc and llvm) and/or bootstrap dedicated toolchain just for
the purpose of building some software. This is too much burden compared
to ~2k lines of .C + .H code from GCC... just because someone can misuse
some legitimate feature.

My point is that we shall not decide for users whether something could
be misused. If someone wants to shoot into his or her foot, we shall not
block it. I consider these concerns as exaggerated as libatomic is
generally safe and simple to use.

> Martin

Attachment: signature.asc
Description: OpenPGP digital signature

Home | Main Index | Thread Index | Old Index