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


Groups > comp.lang.c > #96624

Re: compound assignment to atomic type

From Tim Rentsch <txr@alumni.caltech.edu>
Newsgroups comp.lang.c
Subject Re: compound assignment to atomic type
Date 2016-11-15 10:42 -0800
Organization A noiseless patient Spider
Message-ID <kfnvavoshyr.fsf@x-alumni2.alumni.caltech.edu> (permalink)
References <c023fb24-93f5-463d-8618-e19499f78f0a@googlegroups.com> <o07q85$kbl$1@dont-email.me> <kfntwbbtdde.fsf@x-alumni2.alumni.caltech.edu> <o0b49f$2p5$1@dont-email.me>

Show all headers | View raw


"Chris M. Thomasson" <invalid@invalid.invalid> writes:

> On 11/13/2016 10:59 AM, Tim Rentsch wrote:
>> "Chris M. Thomasson" <invalid@invalid.invalid> writes:
>>
>>> On 11/10/2016 7:34 PM, spacewar@gmail.com wrote:
>>>> I'm confused about C11 compound assignments with E1 (left hand side)
>>>>  {} being an atomic type.
>>>>
>>>> 6.5.16.2 p3 states:
>>>>     If E1 has an atomic type, compound assignment is a
>>>>     read-modify-write operation with memory_order_seq_cst memory order
>>>>     semantics.
>>>>
>>>> Footnote 113 says
>>>>     Where a pointer to an atomic object can be formed and E1 and E2 have
>>>>     integer type, this is equivalent to the following code sequence [...]"
>>>> with the code sequence using atomic_compare_exchange_strong().
>>>>
>>>> On the other hand, 7.17.7.5 p5 states:
>>>>     NOTE The operation of the atomic_fetch and modify generic functions are
>>>>     nearly equivalent to the operation of the corresponding op= compound
>>>>     assignment operators.  The only differences are that the compound
>>>>     assignment operators are not guaranteed to operate atomically, [...]
>>>>
>>>> Doesn't that directly contradict 6.5.16.2 p3 and footnote 113?
>>>>
>>>> GCC 6.2.1 generates atomic RMW code for compound assignments with
>>>> atomic LHS, but the NOTE in 7.17.7.5 makes me worry about that being
>>>> non-portable.
>>>
>>> FWIW, just to be safe, its much better to use the actual atomic
>>> functions to perform operations on atomic types.  They let you
>>> specifically define exactly what you want, and what type of memory
>>> order semantics that particular operation requires for your specific
>>> program's needs.
>>>
>>> If you use normal C to, say, increment something like foo = foo + 1
>>> where foo is an atomic type, the compiler will use strong CAS, and
>>> memory_order_seq_cst for a mem order.  This is just, usually, way to
>>> strong for most work dealing with atomics.
>>
>> That is an interesting statement.  What do you recommend in place
>> of memory_order_seq_cst, perhaps under various scenarios?
>
> Well, if your building a custom lock-free container, perhaps
> memory_order_acquire/release is enough.  Or if your building a proxy
> collector, RCU like, a memory_order_consume can be used instead of an
> acquire.  It really depends on the algorithms specific
> needs.  memory_order_seq_cst is just too strong for a lot of
> synchronization algorithms, and can really destroy performance.

I see.  IIUC, what you're saying is that using memory_order_seq_cst
all the time is too expensive, so in most cases more specialized
patterns are used that can employ less expensive sequencing
guarantees.  Did I understand that right or is there something
more?

Back to comp.lang.c | Previous | Next — Previous 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