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