Back to General and Gameplay Programming

volatile and consistency

Prune · 2010-12-08T20:23:53

There are various articles discouraging the use of the volatile keyword in multithreaded programming because it provides no ordering and atomicity guarantees (needing barriers and/or interlocked instructions).However, in Intel TBB internals one sees code equivalent totemplate<typename T> __forceinline T Acquire(T volatile const &p) { T t = p; _ReadWriteBarrier(); return t; }template<typename S, typename T> __forceinline void Release(volatile S &p, T const t) { _ReadWriteBarrier(); p = t; }volatile clearly does not seem to be useless. Is the barrier by itself sufficient when accessing a shared variable?Say atomicity is already guaranteed by dealing with an aligned dword-sized variable. Then if one thread assigns a value to x and another thread reads x in a loop, I've noticed that if I simply have x = 5; in one thread and while(x != 5) {...} in another (x being a class data member of type int in my test), sometimes there is a non-negligible time elapsed between assignment in the first thread and loop termination--time much longer than the system scheduler granularity. However, if I use the Acquire()/Release() from above, the loop terminates right away every time. My question is, if _only_ a memory barrier is used, is that sufficient, or is volatile _also_ necessary? And what if there are locks around the variable access, is the volatile still necessary? Does it make a difference if the variable is dereferenced through a pointer, or whether it's a member of an object?In the memory hierarchy of register<->L1<->L2<->RAM, since L2 is also shared between CPUs, wouldn't it only be necessary for the shared value to be updated in L2 by one thread for the other thread to see the change? Yet volatile would seem to be inefficient then if it has to reach out all the way to RAM

General and Gameplay Programming Programming

Started by Prune December 07, 2010 08:19 PM

11 comments, last by Prune 13 years, 4 months ago

Red Ant

471

December 08, 2010 05:20 PM

Prune, do you intend to write your own synchronization primitives from ground up or why are you worrying about all this stuff?

Hodgman

52,717

December 08, 2010 05:46 PM

Quote:Original post by Prune
One interesting thing I noticed is that at least for x86 and x86-64, while MSVC has separate _ReadBarrier, _WriteBarrier, and _ReadWriteBarrier, GCC has for all three macros that in the end expand to the same thing, __asm__ __volatile__("" ::: "memory"), and Intel's compiler for both Windows and Linux uses __memory_barrier. Why are they the same for these compilers? I know that older Intel x86 chips did not do write reordering, but I thought x86-64 does.

You'd have to check the assembly language ;)
IIRC, x86 only has one instruction (or instruction modifier) to cause a memory barrier, and it acts as a full fence (ReadWrite). x64 might be the same in only having a full-fence instruction.
Other architectures do have different fence instructions though, which is why MSVC gives you the 3 different macros.

. 22 Racing Series .

Prune

224

Author

December 08, 2010 08:23 PM

Quote:Original post by Red Ant
Prune, do you intend to write your own synchronization primitives from ground up or why are you worrying about all this stuff?

Because I am using it. When possible, I use alternatives to locks, such as lock-free, message passing, double buffering of shared data, etc.

"But who prays for Satan? Who, in eighteen centuries, has had the common humanity to pray for the one sinner that needed it most?" --Mark Twain

~~~~~~~~~~~~~~~Looking for a high-performance, easy to use, and lightweight math library? http://www.cmldev.net/ (note: I'm not associated with that project; just a user)

volatile and consistency

This topic is closed to new replies.

Popular Topics

Recommended Tutorials

volatile and consistency

This topic is closed to new replies.

Popular Topics

Recommended Tutorials

Reticulating splines