And what happens if I synchronize on TaskPool.classinfo in my code?
You don't own that class, you haven't written it and it's not meant to be
extended so why would you do that. Likewise the C# article [1] said
it'd be a bad idea to lock a literal string and the liquid-lock bug [2]
just locks nearby data to synchronize it's code. That this should be a
common source of bugs strikes me as rather odd, but then one could already
wonder why 'lock' is used intransitively. Saying 'lock on sth.' when you
actually
want to lock sth. (data or resource) just pinpoints the underlying issue.
For example the analysis in [2] misses the actual point of the bug. He
wanted to achieve
mutual exclusive usage of a channel but instead of locking the channel he
locked a message.
[1] http://msdn.microsoft.com/en-us/library/ms173179.aspx
[2] http://schneide.wordpress.com/tag/liquid-lock/
For me this whole discussion boils down to the following.
Locks are quite safe if you use them to actually protect a resource.
Locks are very unsafe if you use them as part of an implicit protocol.
