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

[Andrei Alexandrescu]

On 5/29/12 3:06 PM, Dmitry Olshansky wrote:
> 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.

So there is concern about the word per object wasted by the possible 
mutex. I understand.

> 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 :)

Absolutely. I hope you agree that this essentially means you're 
advocating a Java-style approach in which the mutex is implicitly present...

> In any case if mutex is desired, object could have had some other base
> type say SyncObject.

... albeit not in all objects, only a subhierarchy thereof. I posted the 
same thing. Nice :o).

> Or use "synchronized class" to that end, what it does now by the way
> - locks on each method?

TDPL's design of synchronized still hasn't been implemented. The design 
indeed prescribes that all public access to the resource is synchronized.

> 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(!).

Well all of these are nice thoughts but at some point we must 
acknowledge we're operating within the confines of an already-defined 
language.

> *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)

Any post that starts with taking an issue against the waste of one word 
and ends advocating Smalltalk and Obj-C is... ho-hum.


Andrei