Why is “lock (typeof (MyType))” a problem?

Question

MSDN gives the following warning about the lock keyword in C#:

In general, avoid locking on a public type, or instances beyond yo

Answer 1

It's the same problem as with lock(this) - you're locking on a reference which other code has access to, so it could be locking on it too.

If you have two unrelated pieces of code locking on the same reference without intending to exclude each other, then in the best case you could lose a bit of performance due to a lack of concurrency - and in the worst case you could introduce a deadlock.

Answer 2

It is stated also documentation under topic "Managed Threading Best Practices". https://msdn.microsoft.com/en-us/library/1c9txz50(v=vs.110).aspx

It says;

Don't use types as lock objects. That is, avoid code such as lock(typeof(X)) in C# or SyncLock(GetType(X)) in Visual Basic, or the use of Monitor.Enter with Type objects. For a given type, there is only one instance of System.Type per application domain. If the type you take a lock on is public, code other than your own can take locks on it, leading to deadlocks. For additional issues, see Reliability Best Practices.

Use caution when locking on instances, for example lock(this) in C# or SyncLock(Me) in Visual Basic. If other code in your application, external to the type, takes a lock on the object, deadlocks could occur.

Answer 3

Because the result of typeof (MyType) (which is an object of type Type) is widely accessible and other thread can lock on the same object, and hold that lock indefinitely. Then internal logic of MyType has effectively given away significant control over it's synchronization logic. This might not be an actual problem if this is intended, but coding defensively/skeptically should be your modus operandi.

Answer 4

because the target of a lock is ONLY to establish a place to store the lock boolean (Am I locked or not) for other threads to look at....

The common misconception that the target of a lock is actually somehow being locked is just wrong... What is "locked" is, .... nothing, unless in methods which can access some shared memory in an unsafe manner, you write the code to look at the this lock and not proceed until it has been released... using a Type object, as a lock target is wrong because code snippets anywhere in the entire solution process space can access that type object and change the synch block that the lock boolean is stored in. Creating a locally scoped object allows you to better ensurethat only those threads and methods that can access or mess with your "at risk" shared memory can also access and/or modify the lock.

Answer 5

This wouldn't be "an issue" if this modified-parallel form of the advice were followed:

In general, avoid locking on a public type, or instances that you did not create or define. The common constructs lock (this), lock (typeof (MyType)) violate this guideline if you did not create the instance or declare the type..

However, as the above 'cannot be guaranteed' for public types or accessible instances across all encountered code, the MSDN and other sources argue that these should be avoided for Defensive Programming against a singular potential hard-to-detect runtime (Deadlock) issue. This is good advice given that most coders are not very good or diligent about rules..

..and someone who encountered such bug in the wild would be much more adamant about not allowing this specific issue to occur again, by imposing the guidelines stated. (Java 1.0/1.1 with the Threaded AWT UI Model was especially problematic.)

The case of lock ("mylock") is singularly special in that it should be avoided due to string-interning as one generally cannot "know" if they are violating the advice above..

Answer 6

It's dangerous because anything can take that lock so it's difficult or impossible to prevent a deadlock situation.

There used to be an article on this ("Don't Lock Type Objects!" a Dr. GUI article) in with some comments by Rico Mariani. Apparently the article is no longer directly available, but there are 'mirrors' floating around, including at http://bytes.com/topic/c-sharp/answers/249277-dont-lock-type-objects.

Here's an excerpt:

The basic problem here is that you don't own the type object, and you don't know who else could access it. In general, it's a very bad idea to rely on locking an object you didn't create and don't know who else might be accessing. Doing so invites deadlock. The safest way is to only lock private objects.

But wait; it's even worse than all that. As it turns out, type objects are sometimes shared across application domains (but not across processes) in current versions of the .NET runtime. (This is generally okay since they're immutable.) That means that it's possible for ANOTHER APPLICATION running even in a different application domain (but in the same process) to deadlock your application by getting a lock on a type object you want to lock and never releasing it. And it would be easy to get access to that type object because the object has a name—the fully qualified name of the type! Remember that lock/SyncLock blocks (that's a polite word for hangs) until it can obtain a lock. It's obviously really quite bad to rely on a lock that another program or component can lock and cause you to deadlock.