Haiku developer Stephan Assmus (Stippi) has posted the first in a series of articles on the topics of multithreaded applications. Stephan writes: "Though I am programming on BeOS since 1999, only in recent years I have slowly become more comfortable with various multithreading related issues in my programs. So I thought I'd like to share some of my experiences here for beginning programmers or programmers skeptical about multithreading. I hope to be extending this as a series of articles to help learn the benefits and pitfalls of multithreading. All with an emphasis on programming for Haiku's API."
To read all comments associated with this story, please click here.
Member since:2006-01-26
I mean, no offence but anyone coding an OS should be completly familiar with at least those common problems and solutions, don't you think ? In fact I don't really see the point here.
This is basically an article for new developers who are considering writing applications (for Haiku), not the underlying OS. If Haiku's application base is to grow any time soon, it seems like a little education on how to write good multi-threaded apps would be in order, no?
One of the things that has "plagued" BeOS/Haiku application developers for years is the unavoidable multi-threading development model. It is a barrier that can prevent newbie developers from quickly writing good BeOS/Haiku software.
Member since:2007-09-07
Member since:2006-03-15
This is an excellent article. I learned to write code on BeOS, so I consider myself pretty spoiled, API-wise. The multithreaded nature of the OS doesn't really pose that many problems, but beginners or those who started on other platforms will find this a tripping point unless they already have this kind of experience (not as common as you might think) or they are given some sort of introduction like stippi has graciously done. Fine work, if you asked me. 
Member since:2005-08-29
I actually disagree with that. While his example deadlock problem is fine, his solution to it kind of sucks. This won't make much sense to people who haven't read the article, but his solution:
- make Invalidate() pass a message instead of directly trying to notify the listeners (of the data in question)
I would solve it by:
- move Invalidate() 2 lines down, so that unlock() is called before Invalidate()
While his solution solves the problem, it introduces more complexity into the code and perhaps more importantly it adds yet another lock (lock for each message queue which he doesn't show in the article but would be required). He also doesn't follow his own advice of "hold a lock for as short of a time as possible". Invalidate() doesn't require holding the data lock so he shouldn't call it while holding the lock.
Here's my advice for programmers that are new to multithreading:
1) Hold locks for the absolute minimum time required
2) Minimize the number of locks (as performance will allow)
3) Don't use recursive mutexes. If your code requires a recursive mutex, you probably don't understand it well enough to debug it.
Member since:2005-09-14
While his solution solves the problem, it introduces more complexity into the code and perhaps more importantly it adds yet another lock (lock for each message queue which he doesn't show in the article but would be required). He also doesn't follow his own advice of "hold a lock for as short of a time as possible". Invalidate() doesn't require holding the data lock so he shouldn't call it while holding the lock.
The message queues share the window lock in BeOS. Those are implicitly there as Lock A and B in his example, and are taken care of for you by the API in this case.
Edited 2007-09-08 06:14 UTC
Member since:
2007-09-07
Am I the only one who find this whole article a little... Obvious ? I mean, no offence but anyone coding an OS should be completly familiar with at least those common problems and solutions, don't you think ? In fact I don't really see the point here.
But for, ha, beginners, yep great article.