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


Groups > comp.lang.c > #96522

Re: compound assignment to atomic type

From "Chris M. Thomasson" <invalid@invalid.invalid>
Newsgroups comp.lang.c
Subject Re: compound assignment to atomic type
Date 2016-11-13 17:48 -0800
Organization n/a
Message-ID <o0b549$4o0$1@dont-email.me> (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


On 11/13/2016 5:34 PM, Chris M. Thomasson wrote:
> 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.

When one can get away with using memory_order_consume, well, it boils 
down to a nop on a lot of archs out there, except a DEC Alpha!

;^)



> 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.

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