Linked by Thom Holwerda on Sun 9th Sep 2007 18:08 UTC, submitted by koki
BeOS & Derivatives "The primary intention of my previous article was to make it very clear why and when locking is needed in multithreaded applications. In this article, I want to present my experiences in writing a new prototype for a replacement of the document model in WonderBrush and how it is manipulated and rendered asynchronously."
Thread beginning with comment 269946
To view parent comment, click here.
To read all comments associated with this story, please click here.
Vanders
Member since:
2005-07-06

Writing multithreaded applications in C++ is like pulling teeth.


I don't agree. The problem is that a lot of developers just won't or will not understand multi-threading. Using a language that "hides" the locking & message passing details may help mitigate that problem somewhat, but they'll still have very little idea of how it works.

Writing multi-threaded C++ is easy. There are three or four rules to remember and that's about it. Any developer should be capable of it.

Reply Parent Score: 7

TQH ! Member since:
2006-03-16

Exactly.

Reply Parent Score: 1

tuttle Member since:
2006-03-01

I don't agree. The problem is that a lot of developers just won't or will not understand multi-threading.


The majority of developers are incapable of writing multithreaded code with fine-grained locking. That is just a fact. So your approach is to tell these people to learn low level multithreading primitives or go to hell. Great way to get new developers for your niche platform.

Using a language that "hides" the locking & message passing details may help mitigate that problem somewhat, but they'll still have very little idea of how it works.


First of all, scala does not hide the message passing details. It just lets you write a message handler in 1/10th the lines of code compared to C++.

And what is the problem about hiding complexity? Many people use the stl without having the slightest idea about the alorithms used by it. Are you saying that abstraction is bad?

Besides, just because somebody does not get low level threading primitives like semaphores and mutexes does not mean that he is a bad programmer. Maybe he has valuable domain specific knowledge.

And I guess all those people using Erlang to program high performance telecommunications gear must be idiots because they use a language that hides many multithreading problems...

Reply Parent Score: 1

TQH ! Member since:
2006-03-16

'The majority of developers are incapable of writing multithreaded code with fine-grained locking. That is just a fact.'

So most programmers won't understand this article at all then?

Reply Parent Score: 1

Vanders Member since:
2005-07-06

The majority of developers are incapable of writing multithreaded code with fine-grained locking. That is just a fact.


I still don't believe it. You're basically calling the majority of developers idiots.

First of all, scala does not hide the message passing details. It just lets you write a message handler in 1/10th the lines of code compared to C++.


This claim is based on API-specific details. I can write a message handler in C++ for Syllable (& BeOS would be similiar) in under 10 lines of code, and that's with a very generous white-space policy. I could collapse that to 5 lines with BSD-style indentation.

Besides, just because somebody does not get low level threading primitives like semaphores and mutexes does not mean that he is a bad programmer. Maybe he has valuable domain specific knowledge.


I never said it did, but I'd be concerned by any developer who did not have a basic understanding of what is happening below the surface of the code they are developing.

I guess all those people using Erlang to program high performance telecommunications gear must be idiots because they use a language that hides many multithreading problems...


Apart from the fact that is an ad-hominem, it really depends on wether they are using Erlang because they don't understand threading or because Erlang is highly suitable for the given domain-specific problem. As it is the later, your assertion is false.

Edited 2007-09-10 13:59

Reply Parent Score: 5