Any x86 instruction that has lock prefix has full memory barrier. As shown Abel’s answer, Interlocked* APIs and CompareExchanges use lock-prefixed instruction such as lock cmpxchg. So, it implies memory fence. Yes, Interlocked.CompareExchange uses a memory barrier. Why? Because x86 processors did so. From Intel’s Volume 3A: System Programming Guide Part 1, Section 7.1.2.2: For … Read more
I’ve achieved a working example! The main idea received from wiki, but with some changes for C#. The wiki article demonstrates this for static field of C++, it is looks like C# always carefully compile requests to static fields… and i make example with non static one: If you run this example in Release mode … Read more
first, let’s see what says the fox =WHATTHEFOXSAY() is a unique easter egg google sheets function (discovered by @kishkin) that randomly generates a pre-set string of text on user demand which is a huge deal because while the generation is random, the recalculation is not affected by onEdit, onChange nor onOpen events, so with some … Read more
Declaring a volatile Java variable means: The value of this variable will never be cached thread-locally: all reads and writes will go straight to “main memory”. Access to the variable acts as though it is enclosed in a synchronized block, synchronized on itself. Just for your reference, When is volatile needed ? When multiple threads … Read more
Whether it is optimized out depends entirely on compilers and what they choose to optimize away. The C++98/03 memory model does not recognize the possibility that x could change between the setting of it and the retrieval of the value. The C++11 memory model does recognize that x could be changed. However, it doesn’t care. … Read more
Yes, you can read from it and write to it safely – but you can’t do anything compound such as incrementing it safely, as that’s a read/modify/write cycle. There’s also the matter of how it interacts with access to other variables. The precise nature of volatile is frankly confusing (see the memory model section of … Read more
Yes, it is guaranteed that thread 2 will print “done” . Of course, that is if the write to b in Thread 1 actually happens before the read from b in Thread 2, rather than happening at the same time, or earlier! The heart of the reasoning here is the happens-before relationship. Multithreaded program executions … Read more
Volatile is unnecessary. Well, sort of** volatile is used to create a memory barrier* between reads and writes on the variable. lock, when used, causes memory barriers to be created around the block inside the lock, in addition to limiting access to the block to one thread. Memory barriers make it so each thread reads … Read more
On Intel an un-contended volatile read is quite cheap. If we consider the following simple case: public static long l; public static void run() { if (l == -1) System.exit(-1); if (l == -2) System.exit(-1); } Using Java 7’s ability to print assembly code the run method looks something like: # {method} ‘run2’ ‘()V’ in … Read more
volatile is needed if you are reading from a spot in memory that, say, a completely separate process/device/whatever may write to. I used to work with dual-port ram in a multiprocessor system in straight C. We used a hardware managed 16 bit value as a semaphore to know when the other guy was done. Essentially … Read more