On 30-05-2012 21:12, Andrei Alexandrescu wrote:
On 5/30/12 12:03 PM, Steven Schveighoffer wrote:
On Wed, 30 May 2012 14:32:59 -0400, Andrei Alexandrescu
<[email protected]> wrote:
On 5/30/12 10:47 AM, Steven Schveighoffer wrote:
Yes, you can just use a private mutex. But doesn't that just lead to
recommending not using a feature of the language?
I don't think so. Synchronized classes are the unit of scoped locking
in D. If you want to do all scoped locking internally, make the class
private.
Maybe you didn't read thoroughly the first part of my post (the example
that shows a deadlock that is easily preventable if the mutex isn't
exposed).
The mutex is not exposed.
I'm trying really hard to not to be rather impolite here, but I don't
know how else to put it: You seem to be the only one who subscribes to
this definition of "exposed". I like to think that there are varying
degrees of exposing resources in programming. The mutex may not be
directly exposed in the sense that you can obtain a reference (though in
reality in all compiler implementations, you can), but it is exposed in
the sense that you can lock and unlock it, which is a mutation of state
and program flow.
I think we need to set aside this matter about what exposing something
really means. The mere fact is that you can lock and unlock the mutex of
any object.
The issue is that it's possible to hijack the mutex that you
are using to protect the class data in order to protect *external* data.
Hijacking is not possible if the mutex is private (i.e. a private
member).
So great! Just don't use the builtin object mutex, because it exposes
possible race conditions. But then why do we have it (the object hidden
mutex)? And now I can't use synchronized classes to ensure the whole
thing is protected, I have to write all my functions like this:
void foo()
{
synchronized(this.mutex) // lock a private mutex
{
}
}
This is a good example. But many synchronized classes are actually
meaningful (e.g. the classic synchronized queue etc).
Andrei
--
Alex Rønne Petersen
[email protected]
http://lycus.org
