Java "volatile" alternative in C++ under Windows?

[joseph_w]

I know from Java that having two threads sharing a global variable can cause two problems:
1) Each thread can "cache" its own copy of the variable and manipulate this copy from now on.
2) When editing the global variable at the same time by both threads this can result in unexpected results.

I can solve the second problem using critical sections in WinAPI but first problem is what I don't know how to solve.

Note: I know that in C++ there is a "volatile" keyword but as I understand it has a different meaning than that of Java.

[Codeplug]

Critical sections, and all Win32 synchronization primitives, solve 1 and 2.

gg

[2kaud]

volatile in c++ is a hint to the compiler that the value of the variable may change in a way that the compiler may not anticipate and so when the value of the variable is required any value already held in registers etc shouldn't be used but the value should be obtained directly from the memory for which it is allocated.

[OReubens]

Critical sections, and all Win32 synchronization primitives, solve 1 and 2.

No they don't. or tather, the sync primitives don't do this in and by themselves.

Rather, the C++ language definition will take care of creating a read/write gate because it needs to "resolve all side effects" before doing the call into the sync primitive.
And likewise the CPU will do the same around a call so it'll clear the CPU pipeline before doing the call and before doing the return (or at least achieve that effect).


volatile as 2kaud said is a compiler hint. DO not make assumptions about what a compiler will do with this, it is perfectly valid for a compiler to totally ignore the volatile entirely (and some do).
Your compiler manual will typically point out what volatile does in that specific compiler and if you so desire, you can make non-portable assumptions in your code based around those compiler specifics.
If you need portability, use the stuff in the <atomic> header

[Codeplug]

>> No they don't. or rather, the sync primitives don't do this in and by themselves.
"Pull over, pull over - semantics police!"
So they don't solve 1 and 2 in and by themselves, but by them being there, they solve 1 and 2.

I want to recall from a Herb Sutter talk on Prism that the compiler is actually a little bit smarter than "read/write gate here due to external call that I don't have the source to". Of course its a lot more complex than that

>> volatile as 2kaud said is a compiler hint. DO not make assumptions about what a compiler will do with this, it is perfectly valid for a compiler to totally ignore the volatile entirely (and some do).
"inline" is hint - volatile is not. Any compiler that completely ignores it isn't a standard implementation. Some compilers have added semantics to the volatile keyword that go beyond what the standard specifies - the manual is indeed your friend here.

gg

[OReubens]

>> No they don't. or rather, the sync primitives don't do this in and by themselves.
"Pull over, pull over - semantics police!"
So they don't solve 1 and 2 in and by themselves, but by them being there, they solve 1 and 2.

It goes a bit beyond just semantics. ANY function call will cause a gating except when the compiler "knows" the function can't touch the variable.

I want to recall from a Herb Sutter talk on Prism that the compiler is actually a little bit smarter than "read/write gate here due to external call that I don't have the source to". Of course its a lot more complex than that

Yes, it is.

"inline" is hint - volatile is not. Any compiler that completely ignores it isn't a standard implementation. Some compilers have added semantics to the volatile keyword that go beyond what the standard specifies - the manual is indeed your friend here.

And for C++11 the manual very clearly states volatile is for hardware access only (interrupts on the same thread) and not to be used for multithreading, you should use the <atomic> stuff for multithreading access.
I don't have the book handy to point out the actual section. Any online references somewhere ?

So volatile does not require a compliant compiler to force rereads/writes (=gating) at every point. It is acceptable for the compiler to disable interrupts temporarily perform a lengthy bit of code with a volatile in a register, and update the memory only just before enabling interrupts again. I have compilers that behave exactly like that and they are (or at least claim to be C++ compliant), I've never went to the trouble of actually testing them for every compliance item.

[2kaud]

I don't have the book handy to point out the actual section. Any online references somewhere ?

This gives the Jan 2012 draft version of c++14 (free!)
http://www.open-std.org/jtc1/sc22/wg...2012/n3337.pdf

[Codeplug]

>> And for C++11 the manual very clearly states volatile is for hardware access only (interrupts on the same thread) and not to be used for multithreading, you should use the <atomic> stuff for multithreading access.
Agreed.

>> So volatile does not require a compliant compiler to force rereads/writes (=gating) at every point.
Agreed.

When I say volatile isn't a hint, I mean that conforming implementations should do what 2kaud described in post #3. In addition to emitting real memory accesses, the compiler can not reorder volatile accesses with respect to each other.

Here's an old quote from N3092 on a similar topic: http://cboard.cprogramming.com/c-pro...tml#post964990

gg