Any chance to avoid monitor field in my class?

[Yuriy via Digitalmars-d-learn]

> 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).
Hm.. Stack/emplace, arrays, n-dimensional arrays? :) Besides, if 
we're talking of D as a system language to replace C++ and to 
scratch everything out of a silicon wafer (also think of embedded 
platforms here), it's crucial for me to be able to control such 
things. From my experience, in a 5000-class project you would 
have about 20 classes that need to be synchronized on. Moreover, 
mutex synchronization is not in fashion nowadays, as we tend to 
use transitional synchronization. And so my 4980 classes will 
contain an extra field i don't use. What?? =)

>>> It would not be derived from Object, which has the field. In 
>>> other words, this would crash:
Those are your words.

> Then what is this object? All D objects derive from Object.
Those are your words also =)

> 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.
Yes, i understand that. By implementing a shared class, you're on 
your own with syncing, but also you tell the user, that your 
class doesn't need to be synchronized on. Right?

> Unshared objects, on the other hand, should not ever need 
> synchronization tools, since only one thread has access!
Here's two use-cases.
class A {}
shared class B {}

// Somewhere in code
{
     shared A sharedA; // This would need synchronized() on access.
     A unsharedA; // This would not. But since, the class is 
defined as unshared, we still will have __monitor in it, and that 
is good, since we can cast between unshared A and shared A.

     B b;
     shared B sharedB; // Here in both cases we know, that we will 
never need to sync on b or sharedB, as both of those are "thread 
safe" (it's not our business, how they do it, but they kinda 
are). So do we need this __monitor, which will never be used 
actually?
}