Date: Tue, 4 Jun 2013 06:12:36 -0700 From: mdf@FreeBSD.org To: Andre Oppermann <andre@freebsd.org> Cc: Ed Schouten <ed@80386.nl>, freebsd-mips@freebsd.org, FreeBSD Arch <freebsd-arch@freebsd.org> Subject: Re: Kernelspace C11 atomics for MIPS Message-ID: <CAMBSHm8B01GRgqKtdTF1wcktPNVOsibqUuiUVJhsiN4m6-CaXQ@mail.gmail.com> In-Reply-To: <51ADA308.6040904@freebsd.org> References: <CAJOYFBD502MYbkVR2hnVDTYWOvOUr15=OPyjotNvv%2BZ09vQ1OQ@mail.gmail.com> <51ADA308.6040904@freebsd.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Tue, Jun 4, 2013 at 1:19 AM, Andre Oppermann <andre@freebsd.org> wrote: > On 03.06.2013 16:04, Ed Schouten wrote: > >> Hi, >> >> As of r251230, it should be possible to use C11 atomics in >> kernelspace, by including <sys/stdatomic.h>! Even when not using Clang >> (but GCC 4.2), it is possible to use quite a large portion of the API. >> > > I'm a bit wary of *kernel* developers using C11-native atomics as opposed > to our own atomic API. This could lead to a proliferation of home-grown, > more or less correctly working, locks and variants thereof (mostly less > correct). > I don't understand this. > Atomics and locks are difficult enough to get right and reason about even > with our rather good API and I scream in fear thinking about everyone(tm) > doing their own "optimized" lock or even forgoing it because "it's atomic". > Why would we replace primitives that work? Meanwhile, the C11 atomics are at least as well documented as FreeBSD's, and they're standardized. Why should a future programmer, who understands C11 atomics, need to learn all new names to work on our OS? I would even propose to go as far as disbarring the use of C11 atomics in > the kernel other than inside the officially supported lock API. So compare and swap is hard to reason about? The C11 atomics should be no harder to reason about than our own -- their effects are documented. And we expect kernel programmers, of all people, to actually be careful about choosing their instructions. <digression>Personally, I find both the C11 atomics and FreeBSD's annoying, since "acquire" and "release" semantics are basically an x86 ism. PPC has no notion of this; it has sync and isync and lwsync instructions which are separate from the atomic set, but can be combined to create the same effect. Except the PPC manual is exceptionally explicit about what guarantees sync provides; it gives a mathematical ordering on loads/stores i, j and which effects can be seen when. "Acquire" and "Release" seem to be named because you kinda need one to acquire a lock and kinda need one to release it. But the effect of ordering loads or stores or both doesn't need to be dependent on the store/load, so putting the two together is just an x86 convenience (and an annoyance on at least PPC).</digression> Anyways, that aside, I see no reason to use a home-grown solution when the C standard finally provides one. It seems akin to preferring u_int64_t over uint64_t because we had it first and they changed the spelling on us. Thanks, matthew
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CAMBSHm8B01GRgqKtdTF1wcktPNVOsibqUuiUVJhsiN4m6-CaXQ>