Using Snapshots for Short Locking Times
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."
E-mail Print r 0   32 Comment(s) http://osne.ws/ecd
Thread beginning with comment 269966
To view parent comment, click here.
To read all comments associated with this story, please click here.
Vanders
Member since:
2005-07-06

You clearly have a pet language, so this discussion is kind of pointless, but there is one thing I want to pick up:

Maybe a message handler for one specific message type. If I remember correctly, a BLooper processes BMessage objects which are basically hashtables. So to handle multiple different message type, you end up with a giant switch statement. In each branch of the switch statement, you have to manually extract all message parameters from the BMessage. For a complex message that will be several lines of code for each message type just for the decomposition. And then you need to handle the case where some parameters are not present or of the wrong type, etc.


The thing is, all of this is trivial and no more difficult or error prone than any other form of procedural programming. It's a total non-issue, and irrelevant to any argument about threading issues, other than the fact that message passing is a good solution to reduce locking. How it is implemented is irrelevant. It's well known that C & C++ are verbose when compared to newer HLL's. If Kaj wern't so busy I'd ask him to come tell you about how wonderful and compact REBOL is.

Reply Parent Score: 2

tuttle Member since:
2006-03-01

You clearly have a pet language, so this discussion is kind of pointless,[q]

I don't have a pet language. I just like modern languages with an orthogonal feature set and decent reflection capabilities. C++ has neither.

I used scala as an example of such a language. But any other language with a) pattern matching and b) strong support for immutable data structures would do just fine. For example ocaml or even plain old standard ML.

[q]The thing is, all of this is trivial and no more difficult or error prone than any other form of procedural programming.


So you are saying that writing 10 LOC is no more error prone than writing 1 LOC?

Don't get me wrong here: I used to love BeOS, and I even think that using C++ to write the core OS parts of Haiku is a good idea. I also do not want to criticize the author of that article. But I sincerely think that C++ is a very bad choice as a language to write multithreaded applications.

Reply Parent Score: 1

phoudoin Member since:
2006-06-09

But I sincerely think that C++ is a very bad choice as a language to write multithreaded applications.

Or whatever non HLL. We got it. Thanks.
Now, whatever the language, designing applications that scale well both on responsivness and computing raw power needs developers used to threading design patterns.
No language will know better than you what and where in your application it matter more to use parallelism and where it make no sense at all and, worst case, could even be counterproductive.

Parallelism doesn't oppose procedural language but sequential programming. Two different things. Some language can have built-in parallelism support, sure. And? Doesn't make any threading design pattern article automatically useless.

Edited 2007-09-10 21:02

Reply Parent Score: 1