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 269940
To view parent comment, click here.
To read all comments associated with this story, please click here.
Member since:

It does depend on the available API to a certain degree. Writing multithreaded applications using the BeOS api is certainly less painful then writing them using the Win32 API.

And using a transactional memory library writing low level/high performance multithreaded code can be almost bearable.

But for example implementing message passing is much more pleasant in a language that has support for pattern matching. And generally writing multithreaded code requires good support for immutable data structures.

A garbage collector is also immensely helpful for message passing. C++ has neither of those, so it is just a bad choice for multithreaded applications.

Reply Parent Score: 1

TQH ! Member since:

I don't understand what you are trying to say at all. It sounds like you are saying C++ sucks just because it doesn't have everything you need built into the language. Where did you get the opinion that most BeOS apps are laden with multithreading problems and very unstable. What would those problems be?

Reply Parent Score: 1

Earl Colby pottinger Member since:

I am wondering what examples he has too. Every program that seems to have problems under BeOS appear to be ports of single threaded programs.

Since the code was never multi-threaded in the first place, hacking it to work under BeOS tends to expose design decisions of the original code.

I have not seen any such problems with programs written proper for BeOS except for 'DriveSetup' which always act weird to me.

Reply Parent Score: 3

tuttle Member since:

I was a big fan of BeOS way back. I even wrote some programs for it: . But while BeOS itself was pretty solid for me, I often had stability problems with third party apps.

IMHO the only way to make multithreaded programming acceptable for mere mortals is to have higher level synchronization primitives. Message passing is obviously one way to achieve this. The BeOS people knew that, so they made many of their APIs use message passing.

But writing a message handler in C++ is just a pain. First of all, you need to have strict rules for the ownership of the objects contained in the message. Otherwise you have a memory leak or a double free bug. Then you need to manually decompose the messages. The list goes on and on.

Reply Parent Score: 2