May 30, 2012
Le 30/05/2012 19:19, Andrei Alexandrescu a écrit :
> Must've been another poster. Anyhow, in TDPL's design only synchronized
> classes can be used with the synchronized statement.
>

Which is good.

>> 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 just explained that in another post.

>> 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.
>

As said, I have nothing against synchronized classes.
May 30, 2012
Le 30/05/2012 20:03, cal a écrit :
> On Wednesday, 30 May 2012 at 17:46:11 UTC, Dmitry Olshansky wrote:
>> [snip]
>>>>> 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. :)
>>>
>> Maybe it's livelock?
>>
>> P.S. Just trying to snatched the prize in this little guess-game :)
>
> FWIW, I recently came across the term here:
> http://schneide.wordpress.com/tag/liquid-lock/

I explained that in another post a few minutes ago, and yes, this is it.

Maybe i should write an article on that, I though it was more well known.
May 30, 2012
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
>> <SeeWebsiteForEmail@erdani.org> 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
alex@lycus.org
http://lycus.org
May 30, 2012
On 30-05-2012 21:17, 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 missed that message. I don't think synchronized classes should go
> away. I think synchronize on non synchronized classes should go away.

This is something I can agree on.

-- 
Alex Rønne Petersen
alex@lycus.org
http://lycus.org
May 30, 2012
Le 30/05/2012 21:25, Alex Rønne Petersen a écrit :
> 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
>>> <SeeWebsiteForEmail@erdani.org> 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.
>

Expliciting terms is always useful, even if it seems sometime irritating.
May 30, 2012
On 5/30/12 12:17 PM, 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 missed that message. I don't think synchronized classes should go
> away. I think synchronize on non synchronized classes should go away.

I agree.

Andrei
May 30, 2012
On 5/30/12 12:17 PM, Alex Rønne Petersen wrote:
> The result is a feature that is arguably only useful in small laboratory
> cases. Are you sure we shouldn't revisit shared and try to work out a
> bridge between the unshared and shared world?

We're as always open to suggestions.

>> There exist type systems that avoid locks. They are very restrictive and
>> difficult to work with.
>
> I can think of 3 languages that have monitors in the "type" system: D,
> C# (as a result of the CLR's design; mostly because they wanted Java
> interoperability), and Java. Are you really saying all other type
> systems are difficult to work with just because of this little thing?

Apologies, meant "avoid deadlocks" instead of "avoid locks".


Andrei
May 30, 2012
On 5/30/12 12:22 PM, deadalnix wrote:
> Le 30/05/2012 20:03, cal a écrit :
>> On Wednesday, 30 May 2012 at 17:46:11 UTC, Dmitry Olshansky wrote:
>>> [snip]
>>>>>> 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. :)
>>>>
>>> Maybe it's livelock?
>>>
>>> P.S. Just trying to snatched the prize in this little guess-game :)
>>
>> FWIW, I recently came across the term here:
>> http://schneide.wordpress.com/tag/liquid-lock/
>
> I explained that in another post a few minutes ago, and yes, this is it.
>
> Maybe i should write an article on that, I though it was more well known.

As a side note, I'm highly weary of inventing new terminology. This is a general remark, not related to this particular instance. Most often when I personally found the need to invent a new term, it was because of not having done my homework of looking at related work.

Andrei
May 30, 2012
On 5/30/12 12:25 PM, Alex Rønne Petersen wrote:
> 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
>>> <SeeWebsiteForEmail@erdani.org> 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 don't care as long as it's the correct one. The mutex is not exposed.

Andrei

May 30, 2012
To clarify:

On 5/30/12 12:25 PM, Alex Rønne Petersen wrote:
>  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.

synchronized (object) {
    writeln("about to unlock the object");
    XXX
    writeln("unlocked the object");
}

Replace "XXX" with a construct that unlocks the object.


Andrei