tag:blogger.com,1999:blog-20059199.post7723381980212965363..comments2024-01-26T00:15:14.996-08:00Comments on ++blog: TechEd 2012 background 1 - Race conditions and Interlocked operationsOrion Edwardshttp://www.blogger.com/profile/15865664564356161586noreply@blogger.comBlogger5125tag:blogger.com,1999:blog-20059199.post-51510104985547463932012-09-13T14:03:52.488-07:002012-09-13T14:03:52.488-07:00Thanks for the feedback Darrell and others
Regard...Thanks for the feedback Darrell and others<br /><br />Regarding the atomicity of value++, without any Interlocking or locks, the JIT compiler simply emits inc dword ptr ds:[00B2328Ch] without the lock prefix.<br /><br />This is a single CPU instruction, so at first glance it may appear "atomic", but in actual fact the 3-step load,inc,store is still happening.<br /><br />Regarding cache decoherence - in theory this could happen, except that I'm running on an intel core i5 which (along with most other ordinary CPU's) implement hardware cache coherency, which would rule it out.Orion Edwardshttps://www.blogger.com/profile/15865664564356161586noreply@blogger.comtag:blogger.com,1999:blog-20059199.post-8478596363477393352012-09-12T03:00:36.164-07:002012-09-12T03:00:36.164-07:00Hi Darrell...
you're actually flat-wrong reg...Hi Darrell... <br /><br />you're actually flat-wrong regarding the ++ operation being thread safe. See the stackoverflow discussion here: http://stackoverflow.com/questions/4628243/is-the-operator-thread-safe<br /><br />Interlocked.Increment is the way to go...insanityhttps://www.blogger.com/profile/16948505302117258598noreply@blogger.comtag:blogger.com,1999:blog-20059199.post-2996108139536626792012-09-06T13:39:25.115-07:002012-09-06T13:39:25.115-07:00No, volatile shouldn't, and wouldn't fix i...No, volatile shouldn't, and wouldn't fix it, that is just my point. The entire block needs a lock, not just one line.Anonymousnoreply@blogger.comtag:blogger.com,1999:blog-20059199.post-8161651879071581572012-09-06T13:08:01.390-07:002012-09-06T13:08:01.390-07:00Volatile will not fix this.
Use LINQPad to try i...Volatile will not fix this. <br /><br />Use LINQPad to try it, it slows things down enough that I can get the error every time, add volatile to the <br />"value" and it will still happenAnonny Mousehttps://www.blogger.com/profile/03284856596200542177noreply@blogger.comtag:blogger.com,1999:blog-20059199.post-45113645567316297782012-09-05T18:45:07.708-07:002012-09-05T18:45:07.708-07:00I think you have the right idea, but I think you m...I think you have the right idea, but I think you may be missing some details. The error that your code is running into is driven by the fact that you are reading and storing a value, then incrementing the original, and then reading and storing the new value. These three operations are the ones you need to be concerned about, not the actual reading and writing of the integer values in single statements.<br /><br />For instance, value++, is already an atomic operation in c#. You do not need to worry about Interlocking to increment. As per the MSDN documentation, reads and writes to standard integers are by default atomic. <br /><br />What you are experiencing is cache decoherence. The Interlock forces a read of the value from memory and write to memory rather than the cache, thus making sure that you get the most updated copy all the time instead of just some of the time. The same can be achieved with marking your value variable volatile.<br /><br />All in all, by introducing a mutex on one line instead of the entire operation, you've simply made a race condition less likely, not impossible. To guarantee no race condition, you would have to put a lock around the entirety of the following:<br /><br />oldValue = value;<br />value++;<br />newValue = value;<br /><br />Still, good post! My comments are c# and .net specific but from a generic standpoint, everything you say is true. There is some good coverage of the fundamentals here and a good lesson for developers of any experience level.Anonymousnoreply@blogger.com