Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.programming.threads > #1840
| 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 |
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 | Next — Previous in thread | Next in thread | Find similar
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