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

[Dmitry Olshansky]

On 30.05.2012 1:41, Andrei Alexandrescu wrote:
>> If anything I'd rather re-implement the whole v-table infrastructure via
>> mixins, templates & friends.
>
> Could you please elaborate how that would help multithreading?
>

It's unrelated to "ease multithreading part strictly speaking.
My observation is that it leads to at least removal of 1 word per 
object. Not a small thing if you happen to use GC, that "sells his 
memory" in 16 byte chunks, chances are you'd waste 2 instead of one.

Again strictly speaking I'm of an opinion that having mutex together 
with object guarded by it is at least better then 2 separate entities 
bound together by virtue of code comments :)
In any case if mutex is desired, object could have had some other base 
type say SyncObject. Or use "synchronized class" to that end, what it 
does now by the way - locks on each method?

More about the actual point is that I've come to believe that there is 
satisfactory way to implement whatever scheme of polymorphism* we want 
within the language on top of structs without 'class' and 'interface' 
keywords, special "flawed" pointer type (i.e. tail-const anyone?), and 
last but not least without new/delete/finalizes (new/delete are still 
overridable, hint-hint) madness.

Ideally I think it should be possible to lower the whole 
interface/object/class infrastructure to code that uses structs with 
direct function pointer tables, etc. Multiple alias this is the key, 
sadly so, otherwise subtyping to multiple interfaces seem not likely.
Then some future compiler may even chose to not provide OOP as built-in 
but lower to this manual implementation on top of struct(!).

*I like the one in Smalltalk or Obj-C. Also I think exposing type-tag as 
ordinal (index inside one global master v-table) instead of pointless 
_hidden_ v-table pointer could be interesting in certain designs. 
Another idea is to try tackling multi-methods via some form of 
compressed 2-stage v-table. (my recent work on generalized tries in D 
sparked some ideas)

-- 
Dmitry Olshansky