synchronized (this[.classinfo]) in druntime and phobos

Dmitry Olshansky dmitry.olsh at gmail.com
Wed May 30 01:33:56 PDT 2012


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


More information about the Digitalmars-d mailing list