Additional Information

  • You have the ability to guarantee a responsive UI when hard locking would otherwise occur.  Just set ReadWriteLocker.UseThisThreadAsPriorityThread = true in the main program where the UI thread is running.

  • Useful whenever multi-threaded programming is being used on a shared resource. This could be inside background workers, custom threads, threads from the thread pool class, Asynchronous Programming (such as Nito.Async), or PFX (Parallel class, PLINQ, and Parallel Tasks).

  • Collections (currently being implemented) which utilizes this thread locker to transparently make itself thread safe.  It also allows collections to know when they are being iterated over, and when iteration completes--useful in caching modifications, then applying them when iteration finishes.

  • You have the ability to determine where hard locks occur. Just change a parameter in the constructor to cause the locker to either assert in debug mode, or throw exceptions in any mode.  Then once you have determined hard locking won't happen, you can remove the overhead associated with hard lock prevention by changing this parameter in the constructor again.

  • Extending the idea above, after using NHLReaderWriterLockSlim to find these deadlock situations, you can switch back to the (currently) better performing ReaderWriterLockSlim.

Last edited Oct 1, 2010 at 3:17 PM by TamusJRoyce, version 9

Comments

No comments yet.