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

Groups > comp.programming.threads > #1826

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

Show all headers | View raw

frege <gottlobfrege@gmail.com> writes:

> On Jan 28, 3:10 am, Anthony Williams <anthony....@gmail.com> wrote:
>> frege <gottlobfr...@gmail.com> writes:
>>
>> > I'm saying that volatile is all that is needed in this situation.
>> > Possibly depending on what the proper definition of volatile (and
>> > memory) is.  But in particular, fences and memory ordering are NOT
>> > needed.  And that this is rare in threading.  Typically volatile isn't
>> > very useful with threads, and novices think it is.  This is a counter-
>> > example.
>>
>> No, it isn't. Under C++0x, volatile still has nothing to do with
>> threading. If you rely on volatile to have one thread read data written
>> by another then you have a "data race" and undefined behaviour. You need
>> atomic operations, even if they are memory_order_relaxed.
>>
>
> I'll try to keep it short, since I have similar responses elsewhere in
> this thread.
> Basically, prior to C++0x I would have used volatile (+ aligned int)
> as the closest approximation to what was required here - avoid having
> the value cached forever (ie in register or whatever) but avoid memory
> barriers.
>
> With C++0x it looks like I would use atomic<int> with
> memory_order_relaxed.
> I wonder if anyone has described/explained how that is subtly
> different than a normal int, even an aligned one.

All operations on an atomic<int> are atomic, whereas on an aligned int
they are not.

e.g.

atomic<int> ai;
int i;

ai++; // LOCK XADD on x86, or equivalent
i++; // INC on x86, which is non-atomic read / increment value /
non-atomic write 

See http://www.devx.com/cplus/Article/42725 for an example of how i++ is
not atomic on real systems.

> There may be an additional point of interest in the example:
> I'm not exactly sure of the wording/def'n of "data race" in C++0x, but
> I'd be interested to know if there is technically a data race in the
> example, because I think the algorithm *should* work.  If it
> technically could be seen as a data race, and thus undefined
> behaviour, I think the defn of data race needs to be looked at.  I
> don't think there are issues, but it is an interesting example that
> skirts the edge of many issues.

A data race occurs when there are two accesses to the same memory
location from separate threads, at least one of which is a write, and at
least one of which is not atomic, and where neither happens-before the
other. The happens-before ordering must come from external code
(e.g. acquire/release on an atomic variable, lock/unlock of a mutex,
etc)

If all accesses to a variable are atomic (even relaxed) then there is no
data race on that variable.

>> No, you need atomic<int> with memory_order_relaxed operations and
>> atomic_signal_fence() to prevent compiler reorderings.
>
> I'm not sure there are any compiler reordering issues in this
> example.  In particular, where would the fences go?!

I haven't thought about it enough; it might be that they won't help,
since relaxed operations to separate variables can be reordered at the
CPU level anyway.

>> > And back to my original thoughts - looking at this example, does it
>> > shed any insight into compiler optimizations, threading, visibility,
>> > etc.  In particular, how long can the reader see 0 "after" the writer
>> > has issued its write of X.  
>>
>> "within a reasonable period of time". i.e. it can't cache the value forever.
>>
>
> For some def'n of reasonable - see my comparison to copyright
> extensions else-thread.

Yes, "reasonable" is QoI. In general, compilers and CPUs are not out to
get you, though.

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 frege <gottlobfrege@gmail.com> - 2011-01-27 21:34 -0800
  Re: forcing the compiler to reload from memory with c++0x frege <gottlobfrege@gmail.com> - 2011-01-28 19:43 -0800
    Re: forcing the compiler to reload from memory with c++0x Anthony Williams <anthony.ajw@gmail.com> - 2011-01-30 22:07 +0000
  Re: forcing the compiler to reload from memory with c++0x Anthony Williams <anthony.ajw@gmail.com> - 2011-01-28 08:10 +0000
    Re: forcing the compiler to reload from memory with c++0x Dmitriy Vyukov <dvyukov@gmail.com> - 2011-01-28 00:45 -0800
      Re: forcing the compiler to reload from memory with c++0x Anthony Williams <anthony.ajw@gmail.com> - 2011-01-28 09:31 +0000
  Re: forcing the compiler to reload from memory with c++0x Dmitriy Vyukov <dvyukov@gmail.com> - 2011-01-28 00:09 -0800
    Re: forcing the compiler to reload from memory with c++0x Alexander Terekhov <terekhov@web.de> - 2011-01-29 15:49 +0100
      Re: forcing the compiler to reload from memory with c++0x Andy Venikov <swojchelowek@gmail.com> - 2011-01-31 15:53 -0500
    Re: forcing the compiler to reload from memory with c++0x frege <gottlobfrege@gmail.com> - 2011-01-28 19:28 -0800
      Re: forcing the compiler to reload from memory with c++0x Dmitriy Vyukov <dvyukov@gmail.com> - 2011-01-29 01:41 -0800

csiph-web