Re: [PATCH 1/2] Optimize generic spinlock code and use C11 like atomic macros.

[Torvald Riegel <triegel at redhat dot com>]

On Mon, 2017-02-27 at 17:57 +0000, Szabolcs Nagy wrote:
> On 26/02/17 20:35, Torvald Riegel wrote:
> > On Sun, 2017-02-26 at 21:29 +0100, Florian Weimer wrote:
> >> * Torvald Riegel:
> >>
> >>>> … like this, it would change the C++ name mangling of anything related
> >>>> to pthread_spinlock_t.  It is defined as a typedef, so the mangling
> >>>> uses the definition to refer to the type, not the name, according to
> >>>> the language rules, where typedef does not create a new type, and
> >>>> typedefs with the same definition can be used interchangeably.
> >>>
> >>> I'm not saying that we should change the definition to a union.  What
> >>> 2.14.2 in the document cited above states is that the pointers to the
> >>> union and the individual parts are interchangeable.  So we can use a
> >>> pointer to a part (ie, non-volatile) interchangeably with the pointer to
> >>> the union that we use internally.
> >>
> >> The relevant quote from that document (C memory object and value
> >> semantics: the space of de facto and ISO standards) is:
> >>
> >> | The standard says: 6.7.2.1p16 “The size of a union is
> >> | sufficient to contain the largest of its members. The value of
> >> | at most one of the members can be stored in a union object
> >> | at any time. *A pointer to a union object, suitably converted,*
> >> | *points to each of its members (or if a member is a bit-field,*
> >> | *then to the unit in which it resides), and vice versa.*” (bold
> >> | emphasis added).
> >>
> >> So I think this is only valid if you actually start with a union
> >> object.  A plain top-level definition of a volatile int is not a union
> >> member, so this rule does not apply (in the “vice versa” part).
> > 
> > Then we'll have to agree to disagree.  What do others think about this
> > question?
> 
> i think the standard says that
> 
> volatile int x;
> *(int*)&x;
> 
> is undefined and i think
> 
> int r = *p;

At least on the architectures that already use the __atomic builtins, we
never perform such an access -- everything goes through __atomic*.  On
other architectures, we already use plain, non-volatile accesses to
emulate real atomics (eg, see atomic_store_relaxed).  ISTM that we
wouldn't be making things worse in the sense that we already make
assumptions about what the compiler would do or would not (e.g., the
compiler does not store to *p again as in your third example).