May 30, 2012 Re: synchronized (this[.classinfo]) in druntime and phobos | ||||
---|---|---|---|---|
| ||||
Posted in reply to Andrei Alexandrescu | 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 Re: synchronized (this[.classinfo]) in druntime and phobos | ||||
---|---|---|---|---|
| ||||
Posted in reply to cal | 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 Re: synchronized (this[.classinfo]) in druntime and phobos | ||||
---|---|---|---|---|
| ||||
Posted in reply to Andrei Alexandrescu | 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 Re: synchronized (this[.classinfo]) in druntime and phobos | ||||
---|---|---|---|---|
| ||||
Posted in reply to deadalnix | 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 Re: synchronized (this[.classinfo]) in druntime and phobos | ||||
---|---|---|---|---|
| ||||
Posted in reply to Alex Rønne Petersen | 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 Re: synchronized (this[.classinfo]) in druntime and phobos | ||||
---|---|---|---|---|
| ||||
Posted in reply to deadalnix | 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 Re: synchronized (this[.classinfo]) in druntime and phobos | ||||
---|---|---|---|---|
| ||||
Posted in reply to Alex Rønne Petersen | 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 Re: synchronized (this[.classinfo]) in druntime and phobos | ||||
---|---|---|---|---|
| ||||
Posted in reply to deadalnix | 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 Re: synchronized (this[.classinfo]) in druntime and phobos | ||||
---|---|---|---|---|
| ||||
Posted in reply to Alex Rønne Petersen | 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 Re: synchronized (this[.classinfo]) in druntime and phobos | ||||
---|---|---|---|---|
| ||||
Posted in reply to Alex Rønne Petersen | 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
|
Copyright © 1999-2021 by the D Language Foundation