{"id":3903,"date":"2014-11-13T10:35:57","date_gmt":"2014-11-13T00:35:57","guid":{"rendered":"https:\/\/www.flamingspork.com\/blog\/?p=3903"},"modified":"2014-11-13T10:35:57","modified_gmt":"2014-11-13T00:35:57","slug":"volatile-considered-harmful","status":"publish","type":"post","link":"https:\/\/www.flamingspork.com\/blog\/2014\/11\/13\/volatile-considered-harmful\/","title":{"rendered":"volatile considered harmful"},"content":{"rendered":"

While playing with MySQL 5.7.5 on POWER8, I came across a rather interesting bug (74775 <\/a>– and this is not the only one… I think I have a decent amount of auditing and patching to do now) which made me want to write a bit on memory barriers and the volatile keyword.<\/p>\n

Memory barriers are hard.<\/p>\n

Like, super hard. It’s the kind of thing that makes you curse hardware designers, probably because they’re not magically solving all your problems for you. Basically, as you get more CPU cores and each of them have caches, it gets more expensive to keep everything in sync. It’s quite obvious that with *ahem* an eventually consistent model, you could save a bunch of time and effort at the expense of shifting some complexity into software.<\/p>\n

Those in the MySQL world should recognize this – we’ve been dealing with asynchronous replication for well over a decade as a good way to scale.<\/p>\n

On some CPU architectures (POWER for example) not all loads are created equal. When you load a value from memory, it will be consistent with your thread of execution. That is, with any stores that you<\/strong> have done in this thread of execution.<\/strong> If another thread updates that memory location you may not see that update<\/strong> even if your load occurs after<\/strong> that thread updates that memory location. Think eventually consistent.<\/strong><\/p>\n

If you want up to date reads (and not clobber writes), then you get to do memory barriers! (a topic for elsewhere – the PowerISA document has good explanations of what we have on POWER though, and how load with reserve works).<\/p>\n

What the volatile<\/strong> keyword does is generate load and store instructions. It is useful when talking to hardware, as the load and store instructions are actually doing something there that the compiler doesn’t know about and thus shouldn’t optimize away.<\/p>\n

The volatile<\/strong> keyword does not<\/strong> add any memory barriers. This is important <\/strong>to realize – volatile just makes loads and stores happen for your thread, not in relation to any other threads of execution. <\/strong>Thus, you cannot<\/strong> use volatile as a thread synchronization mechanism at all<\/strong>. It is completely and totally wrong<\/strong>.<\/p>\n

Basically, if you have a volatile variable and you do stores to it in one thread and loads in another, after the store happens, it could be quite a long time<\/strong> before the thread doing the loads sees it! For some applications this may be okay (although I can’t really think of any beyond very very inaccurate status variables)… but if it matters at all<\/strong> for application correctness, volatile is the wrong thing to use.<\/p>\n

Further reading:<\/p>\n