Why is it a bad practice to lock the object we are going to change?

by

From the C# language reference here:

In general, avoid locking on a public type, or instances beyond your code’s control. The common constructs lock (this), lock (typeof (MyType)), and lock ("myLock") violate this guideline:

lock (this) is a problem if the instance can be accessed publicly.

lock (typeof (MyType)) is a problem if MyType is publicly accessible.

lock("myLock") is a problem because any other code in the process
using the same string, will share the same lock.

Best practice is to define a private object to lock on, or a private
static object variable to protect data common to all instances.

In your case, I would read the above guidance as suggesting that locking on the collection you will be modifying is bad practise. For example, if you wrote this code:

lock (otherProductList) 
{
    otherProductList = new List<IProduct>(); 
}

…then your lock will be worthless. For these reasons it’s recommended to use a dedicated object variable for locking.

Note that this doesn’t mean your application will break if you use the code you posted. “Best practices” are usually defined to provide easily-repeated patterns that are more technically resilient. That is, if you follow best practice and have a dedicated “lock object,” you are highly unlikely to ever write broken lock-based code; if you don’t follow best practice then, maybe one time in a hundred, you’ll get bitten by an easily-avoided problem.

Additionally (and more generally), code written using best practices is typically more easily modified, because you can be less wary of unexpected side-effects.

More Related Contents:

  1. Why is lock(this) {…} bad?
  2. Volatile vs. Interlocked vs. lock
  3. Concurrent HashSet in .NET Framework?
  4. Asynchronous locking based on a key
  5. Re-entrant locks in C#
  6. Is Task.Factory.StartNew() guaranteed to use another thread than the calling thread?
  7. Is it OK to use a string as a lock object?
  8. Does a locked object stay locked if an exception occurs inside it?
  9. How expensive is the lock statement?
  10. Monitor vs lock
  11. lock keyword in C#
  12. What are the differences between various threading synchronization options in C#?
  13. Do I need to lock or mark as volatile when accessing a simple boolean flag in C#?
  14. C# manual lock/unlock
  15. Throw a NullReferenceException while calling the set_item method of a Dictionary object in a multi-threading scenario
  16. Why does the lock object have to be static?
  17. When is ReaderWriterLockSlim better than a simple lock?
  18. Cross-Process Locking in C#
  19. Guidelines of when to use locking
  20. How do I update an ObservableCollection via a worker thread?
  21. Question about terminating a thread cleanly in .NET
  22. Thread.Sleep for less than 1 millisecond
  23. What is the impact of Thread.Sleep(1) in C#?
  24. The current SynchronizationContext may not be used as a TaskScheduler
  25. c# working with Entity Framework in a multi threaded server
  26. Thread safe collections in .NET
  27. How to correctly read an Interlocked.Increment’ed int field?
  28. How to lock on an integer in C#?
  29. Writing to file in a thread safe manner
  30. How can I enumerate all managed threads in C#?

Leave a Comment