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


Groups > comp.programming.threads > #1840

Re: forcing the compiler to reload from memory with c++0x

From Anthony Williams <anthony.ajw@gmail.com>
Newsgroups comp.programming.threads
Subject Re: forcing the compiler to reload from memory with c++0x
References (16 earlier) <87r5bjlchs.fsf@justsoftwaresolutions.co.uk> <iipt82$jif$1@news.eternal-september.org> <iipumu$54p$1@news.eternal-september.org> <87mxm7kkug.fsf@justsoftwaresolutions.co.uk> <4D512A6D.B156FC09@web.de>
Date 2011-02-08 11:49 +0000
Message-ID <87ipwulpaq.fsf@justsoftwaresolutions.co.uk> (permalink)
Organization CNNTP

Show all headers | View raw


Alexander Terekhov <terekhov@web.de> writes:

> Anthony Williams wrote:
>> 
>> Andy Venikov <swojchelowek@gmail.com> writes:
>> 
>> > Man, using stand-alone fences is even more complicated than adding
>> > correct ordering semantics to atomic loads and stores.
>> 
>> Yes.  I did suggest not having them in C++0x for that reason --- they
>> look easy, but actually they're even harder to get right than ordering
>> on operations. The others in the room felt that non-memory_order_seq_cst
>> atomics were an experts-only feature anyway, so it wasn't an issue.
>
> I always thought that C++0x acquire load is simply { relaxed load,
> acquire fence } and that C++ release store is simply { release fence,
> relaxed store }. 

That's right. However, if you don't follow that pattern rigidly with
your fences then it is easy to make mistakes.

> Fences are needed to allow code like
>
>   if (atomic_var.load(memory_order_relaxed) == some_interesting_value) {
>     atomic_thread_fence(memory_order_acquire);
>     . . .
>   }
>
> and
>
>   if (we_have_relevant_changes_to_release)
>     atomic_thread_fence(memory_order_release);
>   atomic_var.store(UNLOCKED, memory_order_relaxed);
>
> resulting in less overhead on platforms which support fences (Sparc,
> Alpha, PPC) in the case when fencing is not needed and also allow more
> easy porting of existing code with fences to C++0x.

Yes. Those were some of the reasons people wanted to keep them.

Anthony
-- 
Author of C++ Concurrency in Action     http://www.stdthread.co.uk/book/
just::thread C++0x thread library             http://www.stdthread.co.uk
Just Software Solutions Ltd       http://www.justsoftwaresolutions.co.uk
15 Carrallack Mews, St Just, Cornwall, TR19 7UL, UK. Company No. 5478976

Back to comp.programming.threads | Previous | NextPrevious in thread | Next in thread | Find similar


Thread

Re: forcing the compiler to reload from memory with c++0x Andy Venikov <swojchelowek@gmail.com> - 2011-02-07 18:19 -0500
  Re: forcing the compiler to reload from memory with c++0x Alexander Terekhov <terekhov@web.de> - 2011-02-08 12:35 +0100
    Re: forcing the compiler to reload from memory with c++0x Anthony Williams <anthony.ajw@gmail.com> - 2011-02-08 11:49 +0000
  Re: forcing the compiler to reload from memory with c++0x Anthony Williams <anthony.ajw@gmail.com> - 2011-02-08 08:10 +0000
    Re: forcing the compiler to reload from memory with c++0x Andy Venikov <swojchelowek@gmail.com> - 2011-02-08 18:53 -0500

csiph-web