Linked by Thom Holwerda on Fri 7th Sep 2007 19:38 UTC, submitted by koki
BeOS & Derivatives 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."
Order by: Score:
Great primer on multithreading
by AndrewZ on Fri 7th Sep 2007 20:04 UTC
AndrewZ
Member since:
2005-11-15

That's a nice piece!

Reply Score: 1

SMOC for BeOS?
by AndrewZ on Fri 7th Sep 2007 20:06 UTC
AndrewZ
Member since:
2005-11-15

How about a summary of the 8 students who where sponsored by Google to write code for BeOS?

Reply Score: 5

RE: SMOC for BeOS?
by umccullough on Fri 7th Sep 2007 20:13 UTC in reply to "SMOC for BeOS?"
umccullough Member since:
2006-01-26

How about a summary of the 8 students who where sponsored by Google to write code for BeOS?

If I'm not mistaken, this process isn't completely finished yet. The deadline for the mentor/student evaluations has passed (August 31), but the final submission of code and review by Google hasn't yet expired.

On the other hand, I would also like to see a summary published - maybe with some info from each of the mentors on what each project was, how much of it was completed, and what remains to be done for each.

Edited 2007-09-07 20:14

Reply Score: 4

RE: SMOC for BeOS?
by darkwyrm on Fri 7th Sep 2007 21:01 UTC in reply to "SMOC for BeOS?"
darkwyrm Member since:
2006-03-15

We're working on one. Should be out before too long. ;)

Reply Score: 4

Great but...
by Kyuubu on Fri 7th Sep 2007 20:50 UTC
Kyuubu
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.

Reply Score: 5

RE: Great but...
by umccullough on Fri 7th Sep 2007 21:08 UTC in reply to "Great but..."
umccullough 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.

Reply Score: 8

RE[2]: Great but...
by Kyuubu on Fri 7th Sep 2007 22:56 UTC in reply to "RE: Great but..."
Kyuubu Member since:
2007-09-07

Now that makes more sense to me ;)

Reply Score: 2

RE[2]: Great but...
by darkwyrm on Fri 7th Sep 2007 23:25 UTC in reply to "RE: Great but..."
darkwyrm 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. ;)

Reply Score: 5

RE: Great but...
by averycfay on Sat 8th Sep 2007 05:27 UTC in reply to "Great but..."
averycfay Member since:
2005-08-29

But for, ha, beginners, yep great article.


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.

Reply Score: 1

RE[2]: Great but...
by anevilyak on Sat 8th Sep 2007 06:13 UTC in reply to "RE: Great but..."
anevilyak 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

Reply Score: 2

RE[3]: Great but...
by averycfay on Sat 8th Sep 2007 07:53 UTC in reply to "RE[2]: Great but..."
averycfay Member since:
2005-08-29



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.


I'm not familiar with the BeOS api, but if they are indeed the same locks as in his example (lock A and lock B), his proposed solution wouldn't even work and would deadlock too.

Reply Score: 1

RE[4]: Great but...
by anevilyak on Sat 8th Sep 2007 17:06 UTC in reply to "RE[3]: Great but..."
anevilyak Member since:
2005-09-14


I'm not familiar with the BeOS api, but if they are indeed the same locks as in his example (lock A and lock B), his proposed solution wouldn't even work and would deadlock too.


Actually they wouldn't, they're recursive locks. The way he demonstrates is in fact the way it works when you're working with that API.

Reply Score: 3

About PostMessage...
by JonathanBThompson on Sat 8th Sep 2007 00:07 UTC
JonathanBThompson
Member since:
2006-05-26

From the character known as DeadYak, it's my understanding that BLooper::PostMessage() isn't threadsafe, at least in BeOS. I'm going to need to look and verify if that's also true of Haiku.

Reply Score: 2

RE: About PostMessage...
by laplace on Sat 8th Sep 2007 05:52 UTC in reply to "About PostMessage..."
laplace Member since:
2005-07-06

Using BMessenger::SendMessage should solve the problem.

Reply Score: 2

Exposure
by stippi on Sat 8th Sep 2007 08:40 UTC
stippi
Member since:
2006-01-19

To be honest, I didn't expect so much exposure. I just posted an article to the beginners section of our Haiku developer documents... In fact I was still working on and improving the article based on feedback I got. This whole subject was just something I wanted to start some articles about, share some experience, but I am no guru. I learned stuff in my own applications and I frequently come across code which is riddled with race conditions and locking issues. Or library code which is not re-entrant... multi threading related issues just seem still worth pointing out.

About BLooper::PostMessage(), you are not supposed to lock the looper for that (that's the whole point of messaging), and this means if there are/were problems in PostMessage() not being threadsafe, then they need to be fixed, it's nothing wrong with my artice. IIRC, Haiku's implementation should be thread safe.

And I think the message queue indeed has another lock, but that is only important when messaging is optimized to not go over ports if the target is in the same team, which is of course the case in my example.

I am going to check with our coding gurus and will improve on the article if it contains any errors yet.

Reply Score: 5

BLooper::PostMessage()
by stippi on Sat 8th Sep 2007 08:56 UTC
stippi
Member since:
2006-01-19

...is definitely thread safe in Haiku. It needs to be, because it checks if the looper still exists and if the specified handler is even attached to that looper. Then it uses a BMessenger to actually deliver the message.

Reply Score: 1

RE: BLooper::PostMessage()
by anevilyak on Sat 8th Sep 2007 17:07 UTC in reply to "BLooper::PostMessage()"
anevilyak Member since:
2005-09-14

The thread safety issue JonathanThompson mentioned was in R5's PostMessage specifically ;)

Reply Score: 3

Great article.
by konrad on Sat 8th Sep 2007 09:56 UTC
konrad
Member since:
2006-01-06

Nice work Stippi, I even got a "I want to code in BeOS again" flashback.

Reply Score: 1