On 30-05-2012 19:19, Andrei Alexandrescu wrote:
On 5/30/12 9:56 AM, deadalnix wrote:
Le 30/05/2012 17:46, Andrei Alexandrescu a écrit :
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.

Andrei

I was advocating on being able to lock ANY object, which is out of
control.

Must've been another poster. Anyhow, in TDPL's design only synchronized
classes can be used with the synchronized statement.

Such an object is known to be lockable, and most object will not be. It
will avoid liquid lock, because most thing will not be lockable.

I'm celebrating day 2 of having no idea what a liquid lock is.

I have to confess to this as well. I'm starting to suspect that he really means deadlock. Searching on Google for "liquid lock mutex" literally brings up this very NG thread. :)


Combined with encapsulation capabilities that D already have, exposing
the lock to the entire worlds is easy. It will avoid unexpected lock
from 3rd party code, which is a source of tedious deadlock.

It also open door for locking on struct, that is easily embeded in a
class as value (so constructed and destructed with the class).

The fact that anyone or not can lock/unlock a mutex is a encapsulation
problem and we already have solution in D for that.

.... which can be used with synchronized classes.


Andrei

--
Alex Rønne Petersen
a...@lycus.org
http://lycus.org

Reply via email to