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 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.

Yet it gives no solid reasoning for it. The lock(this) is explained here on SO. I'm interested in lock(typeof(MyType)) case. What is dangerous about it?

Thank you.

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'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.

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

There are always exceptions to the rule and if you know a deadlock situation will not occur then go ahead and use it. Microsoft even seems to go against its own advice in its implementations in the FCL. For example, see the SyncRoot property that is public on many Microsoft classes and is intended for locking

Answer 6

I don't like the whole lock concept of C#. Seems like an architecture bag to me. they should have created an empty class [just like they did with EventArgs] (called Locker for example) which is the only lockable object. This way everybody would follow the best practice....

Or even better, to add it properties such as bool Looked {get; Set;} (or maybe just get i'm not sure)