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

TQH ! Member since:

So just because you had problems with third party apps crashing it's bound to be because of multithreading?

Ownership and garbage-handling, even with a garbage collector, is something you should always know and handle. For instance if you keep just one ref to an object it will most likely never be garbage-collected.

Reply Parent Score: 1