Re: C atomics, lwn.net and major concurrency users...

[sur-behoffski <sur_behoffski@...>]

On Wed, 2020-05-20 19:51 Viacheslav Usov wrote:

>> From:    LWN.net:
>> Title:   Who's afraid of a big bad optimizing compiler?
> 
> This article, written almost a decade after atomics were standardized in C,
> failed to mention them except in passing, and failed to explain why they
> were deemed irrelevant.The article is seriously defective as such.
> 
> Cheers,
> V.

G'day Viacheslav,

My recent C coding has not been in extreme environments, and so I've
tended to try to stick, somewhat ruthlessly/pedantically, to C89.
As such, I have not looked closely at atomics myself.  However,
lwn.net came to my rescue when I was searching for relevant content:



---- (Start semi-sketch of another LWN.net article) ----

Linus started his "386 MMU driver experiment" in 1991, and would surely
be using C89 at that time.  POSIX Threads would be the major library
for concurrency at that time, as it provides primitives that guarantee
single-CPU access, but only at a very significant performance cost.

For things like circular queues, with one process writing frames as the
source merely by manipulating a "head" pointer, and another consuming
frames merely by manipulating a "tail" pointer, a fine-grain, low-cost
memory model for the "head" and "tail" shared variables would be very
valuable for performance... and kernel developers are very, very
interested in low cost/high performance correct code.

So, GNU/Linux came up with its own libraries of mutexes at various
levels during the 90s and Noughties, even as the concept of "atomic"
memory models were being proposed, debated, codified, defined and
combined into the C11 standard (and also C++11).

Two of the biggest libre-source users of concurrency are the GNU/Linux
kernel and the GNU C Library (GLibC).  Apparently GLibC has partially
incorporated atomics, but changing Linux would be a more daunting
task, and, apparently, there are some potential edge cases not clearly
covered by the standard.  Therefore, atomics are not being embraced
quickly within the kernel.

(There are a number of references to other interesting resources in
the LWN article.)

---- (End semi-sketch of LWN.net article) ----



I found out about this from a 2014 article on LWN.net:

---- (Start of summary/extract) ----

        Title:  C11 atomic variables and the kernel
        Author: Jonathan Corbet
        Date:   February 18, 2014
        URL:    https://lwn.net/Articles/586838/

        The C11 standard added a number of new features for the C and
        C++ languages. One of those features — built-in atomic types —
        seems like it would naturally be of interest to the kernel
        development community; for the first time, the language standard
        tries to address concurrent access to data on contemporary
        hardware. But, as recent discussions show, it may be a while
        before C11 atomics are ready for use with the kernel — if they
        ever are — and the kernel community may not feel any great need
        to switch.

        The kernel provides a small set of atomic types now, along with
        a set of operations to manipulate those types. Kernel atomics
        are a useful way of dealing with simple quantities in an atomic
        manner without the need for explicit locking in the code.  C11
        atomics should be useful for the implementation of the kernel's
        atomic types, but their scope goes beyond that application.

        In particular, each access to a C11 atomic variable has an
        explicit "memory model" associated with it. Memory models
        describe how accesses to memory can be optimized by the
        processor or the compiler; the more relaxed models can allow
        operations to be reordered or combined for improved performance.
        The default model ("sequentially consistent") is the strictest;
        it does not allow any combining or reordering of operations in
        any way that would be visible anywhere else in the program.  The
        problem with this model is that it is quite expensive, and, most
        of the time, that expense does not need to be incurred for
        correct operation. The more relaxed models exist to allow for
        optimizations to be performed in a controlled manner while
        ensuring correct ordering when needed.

        [...]

---- (End of summary/extract) ----



As usual, LWN is a subscriber-funded model, and purchasing a
subscription, or going further and donating more money as a sponsor,
is encouraged.

--

cheers,

s-b etc