On 30-05-2012 18:14, Andrei Alexandrescu wrote:
On 5/30/12 9:03 AM, Regan Heath wrote:
On Wed, 30 May 2012 16:46:54 +0100, Andrei Alexandrescu
<seewebsiteforem...@erdani.org> wrote:
On 5/30/12 2:34 AM, 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 think something similar to range design here is the way to go.
It is easy to define something like
template isLockable(T) {
enum isLockable = isShared!T && is(typeof(T.init.lock())) &&
is(typeof(T.init.release()));
}
And allow locking only if(isLockable!Type) .
Now we can create SyncObject or any structure we want. The point is
that
we lock explicit stuff.
But in this design anyone can lock such an object, which was something
you advocated against.
I think there is some confusion here as to what the "problem" is and is
not.
The problem is /not/ that you can lock any object.
The problem is /not/ that we have synchronized(object) {}
The problem is /not/ that we have synchronized classes/methods.
Several posts in this thread assert that such are problems.
The problem /is/ that synchronized classes/methods use a mutex which is
exposed publicly, and it the same mutex as used by synchronized(object)
{}. This exposure/re-use makes deadlocks more likely to happen, and
harder to spot.
This is news to me. How do you publicly access the mutex of a
synchronized class object?
Generally in two ways:
1) synchronized (obj)
2) obj.__monitor
(1) accesses it in order to actually do locking, but if obj is an
instantiation of a class that uses the this reference internally for
locking, you end up with potential deadlocks. Therefore, you can say
that obj's mutex is exposed. This isn't necessarily bad, because if obj
does *not* use its this reference for synchronized statements, nothing
will blow up. This is why the OP was about banning synchronized (this).
(2) is an undocumented feature of the language that druntime (and maybe
some phobos code) makes use of to create/alter/delete monitors.
Andrei
--
Alex Rønne Petersen
a...@lycus.org
http://lycus.org
