Any chance to avoid monitor field in my class?

[Steven Schveighoffer via Digitalmars-d-learn]

On Thu, 08 May 2014 14:17:42 -0400, Yuriy <yuriy.glukhov at gmail.com> wrote:

> On Thursday, 8 May 2014 at 17:49:01 UTC, Steven Schveighoffer wrote:
>> To what end? What are you trying to save?
> I'm trying to reimplement std.variant in a nice OOP way, that supports  
> CTFE, zero-size and a minimal amount of void*-casts. For that i'm using  
> my VariantPayload(T) class, which i want to be as small as possible, as  
> this is supposed to be an utility class which you never know how will be  
> used.

Well, I don't think I know enough to judge whether what you are doing is  
worthwhile...

But my question more was about where do you plan to put so many of these  
objects that you will save a significant amount of bytes, aside from the  
heap (which already uses 16-byte blocks).

>> It would not be derived from Object, which has the field. In other  
>> words, this would crash:
>>
>> synchronized(cast(Object)obj) { ... }
> Wouldn't cast(Object) return null here, so that synchronized will throw  
> or assert or smth? I see no reason for a crash.

Then what is this object? All D objects derive from Object.

>> Perhaps you meant unshared classes? No, they don't, but a monitor is  
>> only allocated on demand, so you don't have to worry about it.
> Errm.. I'm not sure i understand the subject correctly, but according to  
> Alexandrescu's book, a class declared as shared does not require  
> synchronized() over it. I mean, it manages it's synchronization inside  
> itself, and it's user just has to trust it. And if so, why ever  
> synchronizing() on it?

The meaning of shared is not well defined. Even TDPL is outdated on this.

The idea in the book is that shared types would use memory barriers to  
ensure correct ordering of access, and correct data access. But it does  
not prevent races for multiple threads, you still need synchronized.

Unshared objects, on the other hand, should not ever need synchronization  
tools, since only one thread has access!

-Steve