   Why do Java/C# allow you to synchronize on any object?
  Coworkers suggest that Java's notion of being able to synchronize on any object was something of a disaster (or maybe its just Java's initial idea of threading), which makes me curious as to why C# carried it on. I don't see the point in being able to lock on any old object as opposed to using whatever OS primitives you have available, especially when you consider that 4 bytes are set aside in each and every object to make this happen. Perhaps the main goal is to "integrate" threading into the language, improving expressiveness.  I applaud their efforts, but they bring a new set of responsibility to follow that I consider unnecessary. For example, what object should we lock on? Current wisdom suggests using a secondary Object to act as the lock for the original, because you cannot be sure whether the original object is locking on itself or not. Often, people lock inside the object itself, and it can be hard to know whether a subclass is doing that.It all seems somewhat silly, but I'm not a language designer, so I'm curious if there are better reasons for it.   
  It's an effort to help deal with the complexity of shared state concurrency. Message-passing concurrency is a lot easier to use than shared state concurrency, as exemplified by concurrent languages like Erlang.These higher level approaches to concurrency will be part of C# someday - C Omega, Microsoft Research's C# based language uses higher level concepts based on the join calculus, instead of low level locking around shared data.   