Re: Fw: GCC interpretation of C11 atomics (DR 459)

[Torvald Riegel <triegel@redhat.com>]

On Tue, 2018-02-27 at 12:56 +0000, Ruslan Nikolaev via gcc wrote:
> But, of course, it is kind of annoying that double-width types (and that also includes potentially 64-bit on some 32-bit processors, e.g. i586 also has cmpxchg8b and no official way to read atomically otherwise) need special handling and compiler extensions which basically means that in a number of cases I cannot write portable code, I need to put a bunch of architecture-dependent ifdefs, for say, 64 bit atomics even.

The extension I outlined gives you a portable to use wide CAS, provided
that the particular implementation supports this extension.

Whether the standard covers this extension is a different matter.  You
can certainly propose it to the C and/or C++ committees, but that gets
easier if you can show existing practice.

> (And all this mess to accommodate almost non-existent case when someone wants to use atomic_load on read-only memory for wide types, in which no good solution exists anyway.)

You keep repeating that claim.  You also keep ignoring the point about
what kind of performance programs can expect atomic loads to have, if
they are declared lock-free.

Also note that the use case is *not* about wider-than-machine-word
accesses on read-only memory, but whether a portable use of atomics
(which doesn't have to consider machine word size) can use atomic loads
on read-only memory. 

> Particularly, imagine when someones writes some lock-free code for different types (in templates, macros, etc). It basically uses same C11 atomic primitives but for various integer sizes. Now I need special handling for larger types because whatever libatomic provides does not guarantee lock-freedom (i.e., useless) which otherwise I do not need.

If you use C11 atomics, you're bound to the usage intended by the
standard.  Which means that if you need lock freedom, you must check or
ensure that the implementation provides it to you.  If you make an
implicit assumption there beyond what the standard promises you, you are
not writing portable C11 concurrent code -- you are writing
architecture/platform-specific code.

Now, imagine someone writes atomic code using C11, and expects atomic
loads to actually perform like loads and lot like RMWs -- which is what
most concurrent code does, in particular lots of nonblocking  code ...

> True that wider types may not be available across all architectures, but I would prefer to have generic and standard-conformant code at least for those that have them.

It is conforming to the standard.

> > The standard doesn't specify read-only memory, so it also doesn't forbid
> > the concept.  The implementation takes it into account though, and thus
> > it's defined in that context.
> But my point is that a programmer cannot rely on this feature anyway unless she/he wants to write code which compiles only with gcc.

She/he wants to rely on implementation-specific behavior, so that's not
a problem.

> It is unspecified by the standard and implementations that use read-modify-write for atomic_load are perfectly valid. The whole point to have this standard in the first place is to allow code be compiled by different compilers, otherwise people can just rely on gcc-specific extensions.

And they can, because GCC's behavior conforms to the standard.  It
doesn't have the implementation-specific properties you prefer, but
that's not about the standard but about your personal preferences.

> > The topic we're currently discussing does not significantly affect when
> > we can remove __sync builtins, IMO.
> 
> They are the only builtins that directly expose double-width operations. Short of using assembly fall-backs, they are the only option right now.

We can still have an extension such as the one I outlined.

> > They do care about whether atomic operations are natively supported on
> > that particular type -- and that should include a load.
> I think, the whole point to have atomic operations is ability to provide lock-free operations whenever possible. Even though standard does not guarantee it, that is almost the only sane use case. Otherwise, there is no point -- you can always use locks. If they do not care about lock-freedom, they should just use locks.

The standards actually just promise you obstruction freedom.  Forward
progress guarantees are a part of the intention behind the lock-free
class, but not all of it.  There's address-freedom too, and an implicit
assumption about what rough class of performance a particular operation
is in.

The majority of synchronization code will care much more about
performance than about the operation being actually lock-free or not
(things like signal handlers or C++ unsequenced execution policy the are
exceptions).  Case in point: Lots of concurrent code built out of
lock-free atomics is actually not lock-free but has blocking parts -- so
it couldn't be used in things like signal handlers anyway.

> 
> > Nobody is proposing to mark things as lock-free if they aren't.  Thus, I
> > don't see any change to what's usable in signal handlers.
> It is not obvious to anyone that atomic_load will block.

What's your point?  Iff atomic_load will never block, it will be marked
lock-free.  Programs can check for this, so it will be obvious to them
that whether a certain operation might block.  

> It will *not* for single-width types. So, again we see differences for single- and double-width types.

So? Lock-freedom is a per-type property.