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