Andy's observations as he continues to attempt to know all that is .NET...

Tuesday, April 03, 2012

Double check locking

At my recent Async talk at DevWeek I built an Asynchronous queue that enables the consumers to take advantage of async and await keywords available in C# 5.  You can download the code here, the final step in that implementation was to make use of double check locking.  A delegate came up to me afterwards and said my code wasn’t thread safe, in that I could end up with a partially completed object.  This was due to the fact that the CPU can re-order write operations to optimise memory bus, and that is true of some processors.  In that the reference to the object could be flushed out to main memory before the data associated with the object constructor.  This certainly was the case in .NET 1.1 with certain chip sets not true for your classic x86 and x64 but the Itanium I-A64 family of processor.  The work around was to make the pointer to the constructed object volatile forcing the compiler to place the appropriate memory barrier instructions.

However in .NET 2.0 the CLR team enforced a more strong memory model since they didn’t like the idea of managed code behaving so differently on the final target hardware.  Here is a link to the write up from MSDN mag by Vance Morrison the compiler architect of the .NET runtime explaining why you don’t need to use volatile from .NET 2.0 onwards.

No comments:

About Me

My photo
Im a freelance consultant for .NET based technology. My last real job, was at Cisco System were I was a lead architect for Cisco's identity solutions. I arrived at Cisco via aquisition and prior to that worked in small startups. The startup culture is what appeals to me, and thats why I finally left Cisco after seven years.....I now filll my time through a combination of consultancy and teaching for Developmentor...and working on insane startups that nobody with an ounce of sense would look twice at...