Log in

Previous Entry | Next Entry

Volatile does not thread safe make.

I keep running across code, some old and some new, that uses the volatile keyword in an attempt to make the code thread "safe". Using that is always suspect, and without a truly deep understanding of the underlying hardware I doubt you could ever prove it was safe. With todays modern dual core processors, you can be 100% certain that it is unsafe.

In a nutshell volatile means to fetch the value from memory, and ignore whatever may be in the cache. What does that mean when you have two caches? At any rate when I see these items in the code I remove them. What is doubly irritating about them is that I tend to see them in java. Where classes like AtomicInt and AtomicBoolean are part of the libraries.


( 2 comments — Leave a comment )
Dec. 11th, 2007 07:36 pm (UTC)
what it should mean...
is that the fetch from memory needs to pull from the other processor's corresponding cache line if it's been written to. Otherwise, the shared main mem doesn't make any sense at all. If this is the case (and I don't see how you can successfully release a multi-core processor with separate caches where this is NOT the case) then this would mean that even reading from shared mem could make for a slow process. I do remember seeing a chart at some point that showed a core duo sharing the cache between the two processors - this should eliminate the issue you were talking about. However, the issue you mentioned (cache consistency) should be completely handled by the hardware, and should be invisible to any language you use - hence the word "volatile" probably does not handle or even refer to this situation at all. As far as the code is concerned, the hardware should appear (for code consistency purposes only) as an ideal Turing machine - with one shared memory that is always accessed by instructions directly. The only way a coder should be able to determine whether or not a cache is present at all would be by looking at performance numbers - NOT by code consistency.

Instead, my understanding of the word "volatile" is that, rather than referring to the type of low-level instruction used to access a variable, it tells the compiler that the value in memory could have changed since the last time the currently running thread modified it - therefore the compiler may NOT assume that it knows what the current value in memory is, and thus may not optimize away the variable that refers to that memory location. In this case, ripping out "volatile" in a case where it really belonged could cause some nasty effects...

Thus, the usefulness of "volatile" should not be affected by multicore processors, but you are correct that simply using "volatile" does not in itself make a routine thread-safe - if the person using it did not think more deeply about what it meant to be thread-safe, then indeed the code would be just as incorrect on a single processor machine as it would be on a multi-processor machine.

The only thing I could think of that would be truly different in the multi-processor versus single-processor threading case is that you could indeed have two instructions executing at exactly the same time - and I'm not sure how the hardware handles the fact that one instruction might be a read while another might be a write... Seems like you would need to at least make these memory accesses APPEAR to be serialized to the programmer, perhaps by using transactional memory?

Dec. 15th, 2007 11:53 pm (UTC)
Re: what it should mean...
Well remember that volatile is a key word in the language, so what it actually means is highly dependent on the compiler or interpreter.

I've read about, at a high level, that the code for doing critical sections and mutexes is extremely complex in the face of multi-core/multi-processor systems. Honestly I don't know if the "complex" means it is hard to get correct because it is a "hard" problem, or if "complex" means it is a problem which requires a lot of tedious attention to detail. Both if I were guessing.
( 2 comments — Leave a comment )

Latest Month

July 2011
Powered by LiveJournal.com
Designed by yoksel