Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.c > #96417

Re: compound assignment to atomic type

Show all headers | View raw

On Saturday, November 12, 2016 at 5:07:03 AM UTC-6, Ben Bacarisse wrote:
> I don't see the wording as an outright contradiction.  The problem comes
> down to what atomic means, and the depends on the observer.  x += y is
> atomic to an observer in C, but not (I think[1]) to an observer of
> volatile accesses.  The functions of 7.17.7.5 are (again, I think)
> atomic to all but a hardware observer.
> 
> [1] I'm not an expert in this.  I'd welcome a technical discussion of
> C's atomic primitives because I either don't understand them properly or
> there are other rough edges to the description of them.

There are a number of places where the Standard defines certain syntactic
forms as equivalent to others, where it would be more helpful to define the
standard-mandated behavioral aspects as being equivalent but explicitly
allow for the operations to differ in other regards not covered by the
Standard.

For example, some hardware platforms include operations to read a value,
write a value, and perform various atomic operations on a value.  On some
platforms, the constructs "atomic += 1;" and "atomic = atomic + 1;" may
have usefully-different meanings, and it would be helpful to have the
Standard specify that when an atomic read-modify-write will have different
effect from an atomic read, computation, and atomic write, compilers may
use syntax to distinguish the two forms.  It might also be helpful to
suggest that compilers include an option to reject the use of compound
operators on atomic values in cases where the operation as a whole cannot
be made atomic, or provide a construct to request an atomic read-modify-
write sequence of a form not supported by any existing operators (e.g.
the Freescale KL27 has hardware so that a single CPU instruction can
trigger atomic operation of the form

   ioreg &= ~mask;
   ioreg |= (value & mask);

in cases where mask is a constant with a single run of 1's in its binary
representation), with the semantics that compilers would not be required
to accept any particular form, but would be required to treat as atomic
any forms they accept.

Back to comp.lang.c | Previous | Next — Previous in thread | Next in thread | Find similar | Unroll thread

Thread

compound assignment to atomic type spacewar@gmail.com - 2016-11-10 19:34 -0800
  Re: compound assignment to atomic type Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-11-11 16:04 +0000
    Re: compound assignment to atomic type supercat@casperkitty.com - 2016-11-11 09:01 -0800
      Re: compound assignment to atomic type Tim Rentsch <txr@alumni.caltech.edu> - 2016-11-15 10:54 -0800
    Re: compound assignment to atomic type spacewar@gmail.com - 2016-11-12 00:48 -0800
      Re: compound assignment to atomic type Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-11-12 11:06 +0000
        Re: compound assignment to atomic type supercat <flatfinger@casperkitty.com> - 2016-11-12 11:03 -0800
        Re: compound assignment to atomic type Tim Rentsch <txr@alumni.caltech.edu> - 2016-11-13 10:57 -0800
      Re: compound assignment to atomic type Tim Rentsch <txr@alumni.caltech.edu> - 2016-11-13 10:31 -0800
  Re: compound assignment to atomic type "Chris M. Thomasson" <invalid@invalid.invalid> - 2016-11-12 11:24 -0800
    Re: compound assignment to atomic type Tim Rentsch <txr@alumni.caltech.edu> - 2016-11-13 10:59 -0800
      Re: compound assignment to atomic type "Chris M. Thomasson" <invalid@invalid.invalid> - 2016-11-13 17:34 -0800
        Re: compound assignment to atomic type "Chris M. Thomasson" <invalid@invalid.invalid> - 2016-11-13 17:48 -0800
        Re: compound assignment to atomic type Tim Rentsch <txr@alumni.caltech.edu> - 2016-11-15 10:42 -0800

csiph-web