Le 30/05/2012 01:25, Alex Rønne Petersen a écrit :
On 30-05-2012 01:22, Andrei Alexandrescu wrote:
On 5/29/12 4:17 PM, Alex Rønne Petersen wrote:
On 30-05-2012 01:10, Andrei Alexandrescu wrote:
On 5/29/12 4:06 PM, Alex Rønne Petersen wrote:
Synchronized blocks are good because they
operate on an implicit, hidden, global mutex. You can't screw up with
that.
I think there's quite some disconnect here. If there's any anti-pattern
in this discussion, it's operating on an implicit, hidden, global
mutex.
Walter agreed to eliminate that from D, but never got around to it.
Andrei
I'd love to hear why you think this design is problematic as opposed to
one that lets users accidentally expose synchronization issues to
consumers of their API surface, which is what many people end up doing
since synchronized (this) or even synchronized (this.classinfo) are
allowed at all.
(I've seen countless cases of those two horrible abuses of synchronized
especially from people asking questions on e.g. IRC.)
I think the most egregious example is synchronization by global lock
done in Python and other languages. It has very nice semantics (stop the
world, do something, resume the world), but scales poorly enough to be
universally considered a failure. Quite honest I'm shocked that you're
advocating it.
Andrei
I'm not advocating it. I don't use it myself. I'm just saying that I
find it to be less of an issue than synchronizing on arbitrary objects,
because the latter is error-prone.
And yes, Python is a textbook example of synchronization gone completely
wrong. But that doesn't mean that you don't sometimes have to
synchronize on some global resource, and in those cases, it can be
useful syntactic sugar (but certainly not essential).
I have to agree with Andrei here. The global mutex isn't the solution
either. The mutex should be explicit, and under control (not this).
