On Monday, June 04, 2012 10:51:08 mta`chrono wrote: > Am 31.05.2012 17:05, schrieb Regan Heath: > > .. but, hang on, can a thread actually lock a and then b? If 'a' cannot > > participate in a synchronized statement (which it can't under this > > proposal) then no, there is no way to lock 'a' except by calling a > > member. So, provided 'a' does not have a member which locks 'b' - were > > deadlock safe! > > > > So.. problem solved; by preventing external/public lock/unlock on a > > synchronized class. (I think the proposal should enforce this > > restriction; synchronized classes cannot define __lock/__unlock). > > > > R > > I think it doesn't matter whether you expose your mointor / locking / > unlocking to the public or not. You can always unhappily create > deadlocks that are hard to debug between tons of spaghetti code.
You can always create deadlocks, but if there's something which gives you little benefit but significantly increases the risk of deadlocks (e.g. making it easy to lock on a synchronized class' internal mutex via a synchronized block), then it's valuable to make it illegal. Because while it won't prevent all deadlocking, it _does_ eliminate one case where it's overly easy to deadlock. - Jonathan M Davis