Any chance to avoid monitor field in my class?

[Steven Schveighoffer via Digitalmars-d-learn]

On Thu, 08 May 2014 15:47:46 -0400, Yuriy <yuriy.glukhov at gmail.com> wrote:

>> 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,

How many of these? In order to justify saving 8 bytes per instance, you  
have have a lot. I don't see emplacing thousands or tens of thousands of  
objects on the stack.

> arrays, n-dimensional arrays?

Arrays of objects are stored as arrays of object references, with each one  
pointing at a separate block on the heap.

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

In D, class is not used for such things, struct is.

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

I'm assuming you want D classes, but without the monitor object. D classes  
derive from Object.

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

"Any chance to avoid monitor field in my class?" Those are your words.  
What is it that you want?

>> 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?

A defined shared class I think is supposed to imply that all its methods  
are shared (meaning the 'this' pointer must be shared). It does not imply  
that they are thread safe.

>> 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?
> }

shared != thread safe. You still need to synchronize

-Steve