It seems like this is actually creating a mutual exclusion problem but the point is that we would like to have a memory model in which we don't have to consider memory to be resource that needs to be manually protected by the programmer. This is probably because such a memory model would be harder to reason about and because locks themselves work using shared memory so a different locking mechanism would need to be devised.
MaxFlowMinCut
Consider the following as an example of why mutual exclusion isn't the issue here:
1. Processor A locks variable x
Processor A loads x from memory (with value x = 0) into its cache and runs x += 5
Processor A unlocks variable x
Processor B locks x
Processor B requests x from memory, which still has value 0 because A never flushed its update to main memory.
Processor B uses x = 0, unaware that the "true" value of x is 5 from when A incremented it.
As you can see, the lock is useless here because A's update to x in the critical region isn't ever propagated to main memory. As the slide says, this is a hardware implementation issue, and not a locking issue.
maxdecmeridius
Isn't it possible to also implement the system where we treat these loads as if we're adding a volatile variable? That way the processor would need to load the value from memory each time instead of keeping it in its local cache.
Of course, this way is the naive approach where we would see a much lower performance, but wouldn't it be as effective?
Objects that are declared as volatile are not used in certain optimizations because their values can change at any time. The system always reads the current value of a volatile object when it is requested, even if a previous instruction asked for a value from the same object. Also, the value of the object is written immediately on assignment.
It seems like this is actually creating a mutual exclusion problem but the point is that we would like to have a memory model in which we don't have to consider memory to be resource that needs to be manually protected by the programmer. This is probably because such a memory model would be harder to reason about and because locks themselves work using shared memory so a different locking mechanism would need to be devised.
Consider the following as an example of why mutual exclusion isn't the issue here: 1. Processor A locks variable
xProcessor A loads
xfrom memory (with valuex = 0) into its cache and runsx += 5Processor A unlocks variable
xProcessor B locks
xProcessor B requests
xfrom memory, which still has value 0 because A never flushed its update to main memory.Processor B uses
x = 0, unaware that the "true" value ofxis 5 from when A incremented it.As you can see, the lock is useless here because A's update to
xin the critical region isn't ever propagated to main memory. As the slide says, this is a hardware implementation issue, and not a locking issue.Isn't it possible to also implement the system where we treat these loads as if we're adding a volatile variable? That way the processor would need to load the value from memory each time instead of keeping it in its local cache.
Of course, this way is the naive approach where we would see a much lower performance, but wouldn't it be as effective?
@maxdecmeridius From https://msdn.microsoft.com/en-us/library/12a04hfd.aspx:
Objects that are declared as volatile are not used in certain optimizations because their values can change at any time. The system always reads the current value of a volatile object when it is requested, even if a previous instruction asked for a value from the same object. Also, the value of the object is written immediately on assignment.
One problem I thought of is when multiple updates happen concurrently. There seem to be no guarantees of atomicity (based on discussion here: http://stackoverflow.com/questions/6627596/is-volatile-int-in-c-as-good-as-stdatomicint-of-c0x), so it still won't guarantee correctness.