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

Groups > comp.programming.threads > #1815

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

Show all headers | View raw

Andy Venikov <swojchelowek@gmail.com> writes:

>> std::atomic<int> flags[2] = {0, 0};
>> std::atomic<int> turn(0);
>>
>> void lock(unsigned index)
>> {
>> unsigned int me = index;
>> unsigned int other = 1 - me;
>>
>> flag[me].store(1, std::memory_order_relaxed); //1
>> turn.exchange(other, std::memory_order_acq_rel); //2
>>
>> while (flag[other].load(std::memory_order_acquire) //3
>> && other == turn.load(std::memory_order_relaxed)) //4
>> std::this_thread::yield();
>>
>> return;
>> }
>>
> Prior to your previous post I used to think that load with acquire on
> (3) would make sure that turn.load wouldn't be optimized. But after
> your post it seems that only volatile can make sure of that.

The load-acquire does indeed mean that the compiler must issue the
turn.load unless it can prove that the load of flag[other] can return
false the first time: any values written to turn prior to a
store-release on flag[other] (which will be flag[me] in the other
thread) must be visible at line 4, after line 3 reads the value written
by that store-release.

I am sorry if I was not clear enough in my previous explanations. Yes,
the compiler can optimize things away, and volatile can seemingly make
it put them back again. However, just because the compiler issues a read
does not mean that the CPU will read a value written by another thread
--- it might just return a value from the read-ahead cache, or it's own
write cache, or the value you hope it will read might still be in the
other CPU's write cache.

If the compiler can optimize out a read or a loop or whatever, then that
is because you have got the wrong memory ordering constraints on your
atomic operations. volatile won't help with that.

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

Thread

Re: forcing the compiler to reload from memory with c++0x Andy Venikov <swojchelowek@gmail.com> - 2011-01-31 14:56 -0500
  Re: forcing the compiler to reload from memory with c++0x Anthony Williams <anthony.ajw@gmail.com> - 2011-02-07 22:13 +0000
    Re: forcing the compiler to reload from memory with c++0x Andy Venikov <swojchelowek@gmail.com> - 2011-02-07 17:54 -0500
  Re: forcing the compiler to reload from memory with c++0x Alexander Terekhov <terekhov@web.de> - 2011-02-04 16:39 +0100
    Re: forcing the compiler to reload from memory with c++0x Anthony Williams <anthony.ajw@gmail.com> - 2011-02-04 17:52 +0000
  Re: forcing the compiler to reload from memory with c++0x Anthony Williams <anthony.ajw@gmail.com> - 2011-02-04 08:56 +0000
    Re: forcing the compiler to reload from memory with c++0x Andy Venikov <swojchelowek@gmail.com> - 2011-02-06 23:23 -0500
  Re: forcing the compiler to reload from memory with c++0x Andy Venikov <swojchelowek@gmail.com> - 2011-02-03 17:43 -0500
    Re: forcing the compiler to reload from memory with c++0x Anthony Williams <anthony.ajw@gmail.com> - 2011-02-04 09:04 +0000
    Re: forcing the compiler to reload from memory with c++0x Joshua Maurice <joshuamaurice@gmail.com> - 2011-02-03 15:54 -0800
    Re: forcing the compiler to reload from memory with c++0x Andy Venikov <swojchelowek@gmail.com> - 2011-02-03 17:58 -0500
  Re: forcing the compiler to reload from memory with c++0x Anthony Williams <anthony.ajw@gmail.com> - 2011-02-01 08:24 +0000
    Re: forcing the compiler to reload from memory with c++0x Anthony Williams <anthony.ajw@gmail.com> - 2011-02-04 08:47 +0000
    Re: forcing the compiler to reload from memory with c++0x Andy Venikov <swojchelowek@gmail.com> - 2011-02-03 13:52 -0500

csiph-web