Jump to content
  • Advertisement
Sign in to follow this  
Mercenarey

Multithreading: Boost.Thread seems a bit weak compared to pthreads?

This topic is 3796 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

I have been experimenting with multithreading the past days. Im still quite a newbie, and I may have overlooked something when testing Boost.Thread. I wrote a program expecting that I could at any point launch a thread, which would run until it had done it's job. However, what I found, was that a parent thread waits for a child boost-thread! How come? I looked in the documentation and found this (http://www.boost.org/doc/html/boost/thread.html): void join(); Requires: *this is joinable. Effects: The current thread of execution blocks until the initial function of the thread of execution represented by *this finishes and all resources are reclaimed. Notes: If *this == thread() the result is implementation-defined. If the implementation doesn't detect this the result will be deadlock. Thread::join() is the only way to launch a Boost-thread, and according to the documentation, "The current thread of execution blocks until the initial function of the thread of execution represented by *this finishes and all resources are reclaimed.". So that means, that the parent blocks until the child has done its execution?? Can this be right, or am I doing something wrong? I simply must have misunderstood something, since everyone seems to praise boost to heaven. ---------------- I tested pthread as well, and I had no such problems with it. It ran independently of its parent thread, just as I had expected it to. However, I like boost, because it is crossplatform and very neatly OO-programmed. So I really hope I misunderstood something... Here are my test programs: Boost App Pthreads App Here is the output: Boost Output Pthreads Output As can be seen, with Boost, numbers run consecutively one set after another, while pthreads numbers run intertwined, making it obvious that boost holds the parent until child has run to its end, while pthreads run both simultaneously. Thanks in advance.

Share this post


Link to post
Share on other sites
Advertisement
You misunderstand the documentation.

Your boost::thread begins execution the moment it is constructed, and calls operator() on your creator struct.

The join() method does exactly as you ask - it blocks the calling thread until the boost::thread has finished executing. That means that in your program, the boost::thread is constructed and begins executing. The parent thread then calls join() and waits for the thread to finish. Remove the join(), and both threads will be running.

Share this post


Link to post
Share on other sites
Perfect!
I got it to work. Thanks alot.

However, its a bit annoying that all the tutorials I read so far all use join() :(

Share this post


Link to post
Share on other sites
Yeah and it works exactly the same way with pthread. You use pthreadcreate to create a thread and pthreadjoin to wait for it to end.

Share this post


Link to post
Share on other sites
Just a little nitpick: you should use cout rather than printf. printf is C, cout is C++.

It's also worth noting that cout (and printf, too, probably) aren't thread safe. That means that using these from different threads simultaneously can cause errors or unexpected results. You may need to aquire a lock or use some other syncronisation primitive to ensure that no two threads are attempting to call cout, printf, etc. at the same time.

Share this post


Link to post
Share on other sites
It was just some random example I copy/pasted from a tutorial (and then refitted for pthreads).

However, it is good to know. You just made me realize that with multithreading I can take nothing for granted anymore :)

Share this post


Link to post
Share on other sites
Sign in to follow this  

  • Advertisement
×

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

We are the game development community.

Whether you are an indie, hobbyist, AAA developer, or just trying to learn, GameDev.net is the place for you to learn, share, and connect with the games industry. Learn more About Us or sign up!

Sign me up!