On Thu, 08 May 2014 15:47:46 -0400, Yuriy <yuriy.gluk...@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
