{"id":447,"date":"2011-01-05T14:21:28","date_gmt":"2011-01-05T21:21:28","guid":{"rendered":"http:\/\/mattfife.net\/wordpress\/?p=447"},"modified":"2012-08-12T19:18:11","modified_gmt":"2012-08-13T02:18:11","slug":"why-the-volatile-keyword-probably-isnt-necissary-in-multi-threaded-programming","status":"publish","type":"post","link":"https:\/\/mattfife.com\/?p=447","title":{"rendered":"Why the volatile keyword probably isn’t necessary in multi-threaded programming"},"content":{"rendered":"

Interesting article <\/a>from the Intel guys doing TBB.<\/p>\n

Arch Robinson just removed almost ALL the volatile keywords from Intel Thread Building Blocks.\u00a0 Why?\u00a0 For several reasons, but mostly because he claims that overall it slows your code, probably does not actually solve the underlying ordering problems if your code needs to be portable (a REAL concern on today’s writing of games\/apps for x86, Xbox, PS3, and iPhone devices!),\u00a0 and likely isn’t doing what you think it’s doing anyway.\u00a0 Here’s a pertinent example:<\/p>\n

Sometimes programmers think of volatile as turning off optimization of volatile accesses. That’s largely true in practice. But that’s only the volatile accesses, not the non-volatile ones. Consider this fragment:<\/p>\n

\u00a0   volatile int Ready;\u00a0\n\n\u00a0   int Message[100];\n\n\u00a0   void foo( int i ) {\n\n\u00a0       Message[i\/10] = 42;\n\n\u00a0       Ready = 1;\n\n\u00a0   }<\/pre>\n
It’s trying to do something very reasonable in multi-threaded  programming: write a message and then send it to another thread. The  other thread will wait until Ready becomes non-zero and then read Message. Try compiling this with “gcc -O2 -S” using gcc 4.0, or icc.  Both will do the store to Ready first<\/em>, so it can be overlapped with the computation of i\/10. The reordering is not<\/em> a compiler bug. It’s an aggressive optimizer doing its job.<\/p>\n
You might think the solution is to mark all your memory references volatile. That’s just plain silly. As the earlier quotes say, it will just slow down your code. Worst yet, it might not fix the problem. Even if the compiler does not reorder the references, the hardware might.  x86 hardware will not reorder it. Neither will an Itanium(TM) processor, because Itanium compilers insert memory fences for volatile stores. That’s a clever Itanium extension. But chips like Power(TM) will reorder. What you really need for ordering are memory fences, also called memory barriers.<\/p>\n
So what’s the solution for multi-threaded programming? Use a library or language extension hat implements the atomic and fence semantics. When used as intended, the operations in the library will insert the right fences. Some examples:<\/p>\n
* POSIX threads
\n* Windows(TM) threads
\n* OpenMP
\n* TBB<\/p><\/blockquote>\n
So, when is volatile actually necessary?\u00a0 It turns out there are only 3 portable cases volatile is actually needed:<\/p>\n