Turns out that the answers and the ensuing discussions only consolidated my original reasoning. I now have something in the way of a proof: take the case where the reading thread executes in full before the writing thread starts executing; note the synchronization order that this particular run created; now shift the threads in wall-clock … Read more
Marking a member function volatile is like marking it const; it means that the receiver object is treated as though it were declared as a volatile T*. Consequentially, any reference to x or y will be treated as a volatile read in the member function. Moreover, a volatile object can only call volatile member functions. … Read more
The main difference between AtomicBoolean and volatile from a practical point of view is that the compare-and-set operation isn’t atomic with volatile variables. volatile boolean b; void foo() { if( b ) { //Here another thread might have already changed the value of b to false b = false; } } But seeing as all … Read more
I’m no expert, but cppreference.com has what appears to me to be some pretty good information on volatile. Here’s the gist of it: Every access (both read and write) made through an lvalue expression of volatile-qualified type is considered an observable side effect for the purpose of optimization and is evaluated strictly according to the … Read more
No, you will never get a NPE. This is because volatile also has the memory-effect of introducing a happens-before relationship. In other words, it will prevent reordering of a = one; b = two; The statements above, will not be re-ordered, and all threads will observe value one for a if b already has value … Read more
Returning null is not the issue. The issue is that the new instance may be in a partially constructed state as perceived by another thread. Consider this declaration of Foo. class Foo { public int variable1; public int variable2; public Foo() { variable1 = 1; variable2 = 2; } } Here is how the code … Read more
There’s no equivalent of C#’s volatile keyword in VB.NET. Instead what’s often recommended is the use of MemoryBarrier. Helper methods could also be written: Function VolatileRead(Of T)(ByRef Address As T) As T VolatileRead = Address Threading.Thread.MemoryBarrier() End Function Sub VolatileWrite(Of T)(ByRef Address As T, ByVal Value As T) Threading.Thread.MemoryBarrier() Address = Value End Sub Also … Read more
You should not depend on volatile to guarantee thread safety, this is because even though the compiler will guarantee that the the variable is always read from memory (and not a register cache), in multi-processor environments a memory barrier will also be required. Rather use the correct lock around the shared memory. Locks like a … Read more
What you know is false. Volatile is not used to synchronize memory access between threads, apply any kind of memory fences, or anything of the sort. Operations on volatile memory are not atomic, and they are not guaranteed to be in any particular order. volatile is one of the most misunderstood facilities in the entire … Read more
If the variable is declared volatile then it is undefined behaviour to cast away the volatile, just as it is undefined behaviour to cast away the const from a variable declared const. See Annex J.2 of the C Standard: The behavior is undefined in the following circumstances: … — An attempt is made to modify … Read more