On 30-05-2012 21:49, Andrei Alexandrescu wrote:
On 5/30/12 12:26 PM, Alex Rønne Petersen wrote:
On 30-05-2012 21:17, deadalnix wrote:
Le 29/05/2012 23:33, Andrei Alexandrescu a écrit :
On 5/29/12 1:37 AM, deadalnix wrote:
I would say that breaking things here, with the right deprecation
process, is the way to go.
So what should we use for mutex-based synchronization if we deprecate
synchronized classes?
Andrei
I missed that message. I don't think synchronized classes should go
away. I think synchronize on non synchronized classes should go away.
This is something I can agree on.
Then I'm unclear what we disagree about.
Andrei
OK, so we agree that synchronizing on non-synchronized classes is a Bad
Thing (TM) and should be disallowed. We also agree that (while it is a
somewhat tangential issue) the extra word used in every object is
wasteful (right?).
Now, it's clear that a synchronized class has to store its mutex
somewhere. We could have synchronized classes add an implicit, hidden
field that holds the mutex. Personally, I feel that this might add a
little too much magic (and also forces using the GC), but maybe it's
just me. What I pointed out earlier in this thread is that
core.sync.mutex.Mutex can be used both in a compositional style and
through inheritance. For example:
class MySynchronizedObject : Mutex
{
}
auto mso = new MySynchronizedObject;
synchronized (mso) // this calls lock and unlock on the mutex that mso
*is* since it inherits Mutex directly, i.e. no implicit monitor is created.
{
// ...
}
So basically, I think the question is this: Should synchronized classes
implicitly have core.sync.mutex.Mutex as their base class instead of
object.Object, or should they contain a hidden field? Both options
involve magic, which might be undesirable. The inheritance solution
obviously places restrictions on what base type can be used for
synchronized classes. The hidden field solution means forcing use of the GC.
Am I making sense? Thoughts on this?
--
Alex Rønne Petersen
a...@lycus.org
http://lycus.org
