Le 04/06/2012 10:56, Jonathan M Davis a écrit :
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
At least illegal by default. The programmer may enable it by
him/herself, but not fall in the trap inadvertently.
