On 30.05.2012 3:04, Andrei Alexandrescu wrote:
On 5/29/12 3:56 PM, Alex Rønne Petersen wrote:
A mutex can be stored privately.
It can, but that doesn't mean it will.
Any object can be locked on, meaning no
lock is effectively protected or private or... anything.
To paraphrase you, "An object can be stored privately".
It encourages
shared locks, which is seriously the worst deadlock inducing
anti-pattern to have ever manifested in multithreaded programming.
I'll ignore the hyperbole and continued posturing. Please understand it
does absolutely nothing in carrying your point. A technical question I
have is - what are shared locks, and what are superior alternatives to
them?
I'll intervene. Following famous nerd motto "talk is cheap, show me the
code" I strongly suggest discussing concrete scenarios. All "prone to
deadlock sentiment" is trivia as in buyer beware.
That being said:
class iMutexed
{//implicit intent, explicit details
Mutex mutex;
}
vs
class iMutexed
{//implicit intent, implicit details
//implicit mutex
}
Makes little to no difference. EXCEPT that designer of the class has no
control what so ever over hidden mutex! Thus I believe the best way to
fix it is to (say) require obj be a subclass of Mutex in order to use
synchronized(obj). i.e.
class iMutexed: Mutex
{//explicit intent, implicit details
}
--
Dmitry Olshansky
