Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.programming.threads > #1845
| From | frege <gottlobfrege@gmail.com> |
|---|---|
| Newsgroups | comp.programming.threads |
| Subject | Re: forcing the compiler to reload from memory with c++0x |
| Date | 2011-01-28 19:58 -0800 |
| Organization | http://groups.google.com |
| Message-ID | <5a19e1fa-4fd2-4786-bb98-3eaec8275d8f@t8g2000vbd.googlegroups.com> (permalink) |
| References | (4 earlier) <69d82db7-34be-4de7-86c4-2f39cc1e6df3@m13g2000yqb.googlegroups.com> <4d4221e9$0$17247$426a74cc@news.free.fr> <947b33d5-2509-4f0c-9256-a7c3de35578e@24g2000yqa.googlegroups.com> <87mxmlxxry.fsf@justsoftwaresolutions.co.uk> <ihv8t6$bmr$1@news.eternal-september.org> |
On Jan 28, 3:28 pm, Andy Venikov <swojchelo...@gmail.com> wrote:
> On 1/28/2011 3:01 AM, Anthony Williams wrote:
>
>
> Sorry to be asking too many "stupid" questions, but this area is
> important to understand.
>
> So, if I have
>
> atomic<int> a_int;
> ...
> while (!a_int.get(relaxed))
> {
>
> }
>
> The compiler is allowed to optimize the while loop away?
> Will using atomic_signal_fence (or atomic_thread_fence for that matter)
> force the compiler to emit a code that will do busy-waiting? Do I
> actually need atomic_thread_fence here or will atomic_signal_fence
> suffice? Both of the fences will have to have an "acquire" semantics,
> right? Normally I would use LoadLoad barriers here, but there no such
> thing in c++0x.
>
> Thanks,
> Andy.
I like the structure of this question!
In the past I think I would have used the dreaded volatile here, not
even a LoadLoad. Well, I probably wouldn't have written a busy-wait
loop at all, but if I did, I would have used volatile to avoid the
compiler optimizing it away. And I suspect that would work on most/
any common compilers/systems.
From this discussion, I'm now thinking that *relaxed* here is
sufficient. I would say that the use of atomics is enough to inform
the compiler that you are expecting this value to eventually be
updated from another thread, so it can't be optimized away. It could
be optimized to check "once in a blue moon", but not never.
Maybe some day, like branch-prediction, we will have "frequency-
prediction" where the CPU, based on past runs, determines that a_int
only updates once a week, so it will only run the check approximately
that often. :-)
Tony
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 frege <gottlobfrege@gmail.com> - 2011-01-27 21:56 -0800
Re: forcing the compiler to reload from memory with c++0x Dmitriy Vyukov <dvyukov@gmail.com> - 2011-01-28 00:54 -0800
Re: forcing the compiler to reload from memory with c++0x Andy Venikov <swojchelowek@gmail.com> - 2011-01-28 15:28 -0500
Re: forcing the compiler to reload from memory with c++0x frege <gottlobfrege@gmail.com> - 2011-01-28 19:58 -0800
Re: forcing the compiler to reload from memory with c++0x Anthony Williams <anthony.ajw@gmail.com> - 2011-01-28 08:01 +0000
csiph-web