View mode: basic / threaded / horizontal-split · Log in · Help
May 29, 2012
Re: synchronized (this[.classinfo]) in druntime and phobos
On Tuesday, 29 May 2012 at 17:01:01 UTC, Alex Rønne Petersen 
wrote:
>>>
>>
>> druntime is the low-level runtime library of D. This 
>> discussion is about
>> high-level class design.
>>
>
> I should also add that the reason I started this thread was to 
> prevent common locking errors induced by the anti-patterns 
> synchronized causes. If you're calling *anything* in the 
> core.memory module, I sure hope you know what you're doing in 
> general.
>
> I really don't think these two issues are connected at all.

ok, maybe I read too much into your statement below? it sounded 
as if you wanted to ban this usage from druntime?

Alex Rønne Petersen wrote:
"I've seen several occurrences of synchronized (this) and 
synchronized
(this.classinfo) in both druntime and phobos by now. I propose 
that we
officially ban these patterns with extreme prejudice."
May 29, 2012
Re: synchronized (this[.classinfo]) in druntime and phobos
On 29-05-2012 19:37, Jess wrote:
> On Tuesday, 29 May 2012 at 17:01:01 UTC, Alex Rønne Petersen wrote:
>>>>
>>>
>>> druntime is the low-level runtime library of D. This discussion is about
>>> high-level class design.
>>>
>>
>> I should also add that the reason I started this thread was to prevent
>> common locking errors induced by the anti-patterns synchronized
>> causes. If you're calling *anything* in the core.memory module, I sure
>> hope you know what you're doing in general.
>>
>> I really don't think these two issues are connected at all.
>
> ok, maybe I read too much into your statement below? it sounded as if
> you wanted to ban this usage from druntime?
>
> Alex Rønne Petersen wrote:
> "I've seen several occurrences of synchronized (this) and synchronized
> (this.classinfo) in both druntime and phobos by now. I propose that we
> officially ban these patterns with extreme prejudice."
>

Yes, I do. But I'm not sure what that has to do with my GC.callLocked() PR?

-- 
Alex Rønne Petersen
alex@lycus.org
http://lycus.org
May 29, 2012
Re: synchronized (this[.classinfo]) in druntime and phobos
Le 29/05/2012 18:56, Alex Rønne Petersen a écrit :
> On 29-05-2012 17:52, deadalnix wrote:
>> Le 29/05/2012 14:26, Alex Rønne Petersen a écrit :
>>>>
>>>> shared isn't working properly ATM, so anyway, things will have to
>>>> change
>>>> in regard of shared memory support in the language.
>>>
>>> And it never will. ;)
>>>
>>
>> It has been successful done in other languages and has proven itself
>> useful. This is a difficult backend problem, but it can be solved.
>
> The problem is not in the compiler back end, the problem is that shared
> is completely useless as it is. There's no bridge from shared to
> unshared, making it impossible to work with any real world code base.
>

I'd argue that shared shouldn't contains big stuff. Integers, pointer to 
immutable data, flags, stuff like that.

For such usage, this would work. Still, you comment show that the 
current state of things needs some work, and it is likely to impact both 
shared and synchronized.
May 29, 2012
Re: synchronized (this[.classinfo]) in druntime and phobos
On 29.05.2012 17:59, Jacob Carlborg wrote:
> On 2012-05-29 14:29, Dmitry Olshansky wrote:
>
>> Agreed, awfuly crippled design for a language with Thread-local by
>> default.
>> Looks like we have 'oh my god, what were they thinking' moment here.
>> If anything I'd rather re-implement the whole v-table infrastructure via
>> mixins, templates & friends.
>
> I'm pretty sure that was decided long before D 1.0 and way way longer
> before D2 where TLS was introduced.
>

I know. If anything it's hardly a good excuse, it should have been 
revisited once TLS was introduced. It still can be now.

-- 
Dmitry Olshansky
May 29, 2012
Re: synchronized (this[.classinfo]) in druntime and phobos
On 5/29/12 1:32 AM, deadalnix wrote:
> I already did some comment about this.
>
> Making any object synchronization is a very bad design decision. It is
> deadlock prone, it is liquid lock prone, it cause an overhead on any
> object, and even worse, it is useless most of the time as D promote
> thread locality (which is very good).

Actually I think such a characterization is superficial and biased to 
the extent it becomes wrong.

Locks are deadlock-prone by design, whether used with objects or with 
classic procedural programs. In fact they are better confined to objects 
because the association between the protected data and the 
synchronization object is clear.

> OOP and concurrency are 2 orthogonal topics, and should be handled as
> such.

Well there would be active objects that contradict that. But really it 
is very natural to encapsulate together some data along with the mutex 
that must be acquired to manipulate it. There are known issues with 
inheritance, but they are not introduced by the approach, only exposed 
by it.


Andrei
May 29, 2012
Re: synchronized (this[.classinfo]) in druntime and phobos
On 5/29/12 1:35 AM, deadalnix wrote:
> Le 29/05/2012 01:38, Alex Rønne Petersen a écrit :
>> I should probably add that Java learned it long ago, and yet we adopted
>> it anyway... blergh.
>>
>
> That is what I was about to say. No point of doing D if it is to repeat
> previously done errors.

So what is the lesson Java learned, and how does it address 
multithreaded programming in wake of that lesson?

Andrei
May 29, 2012
Re: synchronized (this[.classinfo]) in druntime and phobos
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
May 29, 2012
Re: synchronized (this[.classinfo]) in druntime and phobos
On 5/29/12 5:26 AM, Alex Rønne Petersen wrote:
> Generalized object monitors is the worst idea in programming language
> and virtual machine design, ever.

I think that's an exaggeration. Care to elaborate a bit?

Andrei
May 29, 2012
Re: synchronized (this[.classinfo]) in druntime and phobos
On 5/29/12 5:29 AM, Dmitry Olshansky wrote:
> Agreed, awfuly crippled design for a language with Thread-local by default.
> Looks like we have 'oh my god, what were they thinking' moment here.

The synchronized class feature was copied by Walter from Java while he 
at the time had only little understanding of multithreading. The 
thread-local by default notion was added much later.

Indeed we'd design things very differently if synchronized came about 
later. The design of "synchronized" described in TDPL and not yet 
implemented is a conciliation of the two.

> If anything I'd rather re-implement the whole v-table infrastructure via
> mixins, templates & friends.

Could you please elaborate how that would help multithreading?


Andrei
May 29, 2012
Re: synchronized (this[.classinfo]) in druntime and phobos
On 5/29/12 12:41 PM, Dmitry Olshansky wrote:
> On 29.05.2012 17:59, Jacob Carlborg wrote:
>> On 2012-05-29 14:29, Dmitry Olshansky wrote:
>>
>>> Agreed, awfuly crippled design for a language with Thread-local by
>>> default.
>>> Looks like we have 'oh my god, what were they thinking' moment here.
>>> If anything I'd rather re-implement the whole v-table infrastructure via
>>> mixins, templates & friends.
>>
>> I'm pretty sure that was decided long before D 1.0 and way way longer
>> before D2 where TLS was introduced.
>>
>
> I know. If anything it's hardly a good excuse, it should have been
> revisited once TLS was introduced. It still can be now.

Don't be hatin'. You'd appreciate the matter considerably more after you 
defined your own language and had its users yell at you for changing 
even a small detail.

The situation is at it is, and there's no need to get agitated. We're 
all on the same boat, trying to make things work out best.


Andrei
1 2 3 4 5 6 7 8
Top | Discussion index | About this forum | D home