On 30.05.2012 12:17, Thiez wrote:
On Wednesday, 30 May 2012 at 06:31:32 UTC, Dmitry Olshansky wrote:
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
}
Forcing synchronized classes to extend Mutex would make it impossible to
create a synchronized subclass of a pre-existing unsynchronized class,
would it not?
Composition. Obviously synchronized subclasses of existing class sounds
strange. The other way around even worse ;)
Wrapping synchronized classes obviously fine.
Unless you want to introduce multiple inheritence. If you
want to go this way at least make it an interface that has special
meaning to the compiler, instead of a class that must be inherited from.
No thanks, multiple inheritance brings too much "coolness". Interface is
no go, locks should be effective.
--
Dmitry Olshansky
