Challenge:
My dear readers, happy new year to all of you! Sorry for being away from you since so long. But no worries. I’m back with new post — means a new thing to share with you!
Before few months back, was reading on .NET Locking mechanism. During that period learnt a lot. So, this post is to share it with you!
Solution:
So, here we go:
1. To clear your threading basics, I would recommend MCTS 70-536 book!
2. Few best links, from the web:
http://www.aspnet101.com/2010/03/50-tips-to-boost-asp-net-performance-part-i/ [Tip#11]
http://msdn.microsoft.com/en-us/library/1c9txz50.aspx
http://msdn.microsoft.com/en-us/library/c5kehkcz.aspx — lock basics! — I loved this example!
“lock (this) is a problem if the instance can be accessed publicly.” — So, if your class is public, Don’t use lock(this) else whole class will get locked by one thread and other threads will keep on waiting for it.
“Best practice is to define a private object to lock on, or a private static object variable to protect data common to all instances.”
http://msdn.microsoft.com/en-us/library/system.collections.hashtable.synchronized.aspx — For syncing
http://thevalerios.net/matt/2008/09/using-readerwriterlockslim/ — Good to know “Under the hood, the lock statement is just syntactic sugar for Monitor.Enter() and Monitor.Exit().If you really want to see for yourself, write a simple lock statement like the one below and open the compiled assembly in Reflector, then look at the IL (not the C#, since Reflector automatically recognizes the underlying lock syntax) — you’ll see calls to [mscorlib]System.Threading.Monitor::Enter and [mscorlib]System.Threading.Monitor::Exit surrounding the code inside.”
While it is a good thing that only one operation can happen to the shared state at any given time, it can also be a bad thing. The whole purpose of the lock is to prevent the corruption of the shared state, so we obviously don’t want to be reading and writing at the same time — but what if two threads are only trying to read at the same time? That’s pretty harmless, right? Nothing can get corrupted if we’re just reading.
In light of this, the lock statement is too cautious and certainly not optimal. Imagine a scenario with 1 thread writing and 10 threads reading — if we use the lock statement then each of the 10 reading threads must execute exclusively when they could be interleaved, leading to inefficient use of resources and wasted effort.
http://msdn.microsoft.com/en-us/library/system.threading.readerwriterlockslim%28v=vs.90%29.aspx — New mechanism in .NET 3.5!
http://kenegozi.com/blog/2010/08/15/readerwriterlockslim-vs-lock
http://blogs.msdn.com/b/pedram/archive/2007/10/07/a-performance-comparison-of-readerwriterlockslim-with-readerwriterlock.aspx
http://www.heikniemi.net/hardcoded/2009/12/readerwriterlockslim-performance/
http://stackoverflow.com/questions/407238/readerwriterlockslim-vs-monitor
“For write-only load the Monitor is cheaper than ReaderWriterLockSlim, however, if you simulate read + write load where read is much greater than write, then ReaderWriterLockSlim should out perform Monitor.”
http://stackoverflow.com/questions/4217398/when-is-readerwriterlockslim-better-than-a-simple-lock
http://stackoverflow.com/questions/59590/lock-keyword-in-c-sharp
http://forums.asp.net/t/1765023.aspx/1
http://jachman.wordpress.com/2006/08/02/best-practices-readerwriterlock/
HashTable is thread-safe if “Hashtable is thread safe for use by multiple reader threads and a single writing thread. It is thread safe for multi-thread use when only one of the threads perform write (update) operations, which allows for lock-free reads provided that the writers are serialized to the Hashtable.” [Source : http://msdn.microsoft.com/en-us/library/system.collections.hashtable.aspx]
Happy Threading and Safe locking! 🙂