Issue is not really concurrency its more about fresh and recent updates not received in local cache of thread. Concurrency i can solve my Mutex,semaphore,Slim,Lock,Monitor.
Must be a better / legal way would be to put the variable updates in between lock calls. Also a comparison of that approach with Volatile would be awesome test to conclude which would be better.
Eric is legend..Second one was really catchy and nice.
But i do not accept that volatile is evil. Its has his own place in multithreading. I agree that its slows the application but then the adverse affects are minimized.
I'm somewhat confused by this article. You talk of variables having different storage allocated on a per-thread basis. Which would suggest you're talking about thread-local storage - only you have to tell the compiler to use that (using ThreadLocal<>), it isn't the default.
It's quite possible that the memory access is being cached (e.g. in a per-core L1 cache the CPU), which might give the symptoms you're describing although I'd expect the situation to resolve itself in time (e.g. when the thread swapped from one core to another). It's also possible that the JITter may decide to optimise out the memory fetch for (what it perceives as being) an invariant variable (although I'm not seeing it do so).
However, I'm not clear on what you're saying the problem is, and I'm not seeing any issues running the supplied code (debug or release). The code runs to completion (even if I add the necessary t1.Join() call in to block the main thread until the looping thread has had a chance to respond).
Threading (and synchronising memory access) is an interesting topic and worthy of discussion. I'm just not sure this article makes the subject any clearer.
You are right thread uses the cache memory ( which for clarity i have termed as local memory) , so the data is stale. Yes we can resolve by using the thread.sleep or block , but then if we have the luxury to make the other thread sleep.
John Brett wrote:
However, I'm not clear on what you're saying the problem is, and I'm not seeing any issues running the supplied code (debug or release). The code runs to completion (even if I add the necessary t1.Join() call in to block the main thread until the looping thread has had a chance to respond).
Do see my video at the last where i have run the complete code in release mode and the memory does not synch. I am not sure it should also reproduce at your end. Do not put sleep or block , then the cache and main memory gets synch and you will not be able to reproduce the problem.
Hi,
Interesting article, but I am wondering if there is not some sort of synchronisation mechanism between the main memory and the thread memory?
Maybe you can re-do the test but add a Sleep(0) call in you threading function?