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

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

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.

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

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

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

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

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

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

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