Sign in to follow this  
Johnell

Multithreaded programming

Recommended Posts

I'm looking to make a little game project of mine and could use some advices.

 

I'll be using C++ and i'm aware of both SFML and SDL. Are there any other good 2D libraries out there for C++ that I should know of? Secondly, I wanna learn more about multithreaded programming so I want to make a game that would force me to use this.

 

Any advices on a game project  and what 2D library to use would be appreciated. 

Edited by Johnell

Share this post


Link to post
Share on other sites

If you want to learn about multithreading, why not do a project just to test and learn the MT stuff, outside of a game?  Trying to learn MT while at the same time doing everything you need for a game is really hard, and will mostly lead to frustration and pain when you're starting out.  Some of the worst bugs to track down and fix are MT bugs.  So, I'd recommend finding some project that you can do as a simple console application that is highly parallelizable, and learn the basics of MT from there.

 

Learn and practice one thing at a time.  When you're competent enough with how MT works, then you can start to think how you can apply it to a game engine.

Share this post


Link to post
Share on other sites

If you wan't to learn MT, go for simple app, like FTP Client-Server. Write it with C for the fun of it.

 

It'l teach you one thing i learned - Don't resort to MT.... like ever... unless really needed.

Edited by Sollum

Share this post


Link to post
Share on other sites

Most engines will hide MT from you, they let you execute your methods/functions every n frames or every n seconds.

If you are looking for a good 2D one that is C/C++, I really like orx, since it allows you to change things in your game really fast and supports nearly everything you need (such as physics and particles). The only drawback is that it has no network support, also, you won't be able to use threads on this one (but as I said, every engine I know will hide MT from you).

 

If you are really into learning MT, go for the classic problems, such as the dining phylosophers:

http://en.wikipedia.org/wiki/Dining_philosophers_problem

Share this post


Link to post
Share on other sites

If you want top-quality reading material with C++ (specifically C++11 and its standard threading library) and threading in mind, I can recommend C++ Concurrency in Action: Practical Multithreading by Anthony Williams (http://www.amazon.co.uk/dp/1933988770) and Herb Sutter's many articles (http://herbsutter.com/).

 

Pre-C++11 you can use boost::thread (nearly identical to std::thread in C++0x/C++11), so any articles concerning std::thread can also be applied to earlier versions of C++ supported by boost.

Share this post


Link to post
Share on other sites

alnite, on 25 Feb 2013 - 15:21, said:
As people have said, multithreading needs to be threaded carefully (pun intended).

If you truly want to learn it, here's a fun thing you can do: make an audio player. With SDL/SFML or whatever GUI lib you decide to use, create a Load, Play, Pause, Stop buttons. Then there should be an audio playing in the background. Try playing a really big audio file (100MB WAVs), without loading it all up at once. Playing audio must be done on a separate thread. Load/Play/Pause/Stop buttons must be able to signal that thread appropriately, and the audio thread must signal back to the main thread.

That's actually what I was going to suggest. +1

Before you get into that bundle of fun, though, you should probably just sit down and play with making small threaded programs that don't do much of anything, like looping counters and the like. Understand what mutexes and critical sections and such do and how to use them. Understand how to terminate a thread from within itself or from another thread. Get familiar with the functionality of your chosen thread-lib basically.

Share this post


Link to post
Share on other sites

What kind of projects would allow me to focus on multithreading, while still building something?

I wrote a multithreaded software raycaster one time and it was really fun, I then ported it to the GPU. I find some things work naturally for MT, the two situations I find it particularly useful in is either when you need to do the same thing over and over again on different data (eg. my raycaster) or when you need to do two tasks that have almost nothing to do with each other.

Share this post


Link to post
Share on other sites
I think a good elementary use for multi threading is when you have a GUI that launches a background task. That's a fairly widely applicable kind of multi-threading. It comes up less often in simple games though, because they tend to need every calculation in every frame, so they just alternate between computing tasks, and drawing to the screen in a single thread.

In general, multi-threading is a way to achieve speedup, so it's not strictly necessary.

The best way to learn multi-threading is probably a book or course. There are a number of techniques that are used and which one is the best varies depending on your application, so you need to know all the tools in order to figure out how to parallelize a particular program. Unfortunately, in my experience courses have not been very comprehensive either, and I cannot recommend a good book.

Share this post


Link to post
Share on other sites

The book The Art of Multiprocessor Programming, is a pretty good beginners book for this subject. However, it uses mostly java programming. But it can easily be transferred to the language of your choice.

Edited by DevLiquidKnight

Share this post


Link to post
Share on other sites

does OpenGL handle multi-threading in the GPU for you when drawing?

 

 

also is there any big difference in performance if you use multi threading for games, say for your update functions ?

Share this post


Link to post
Share on other sites

I haven't dealt with SDL that much, but I can tell you SFML actually has multi-threading, made relatively easy - there's a brief overview of the 1.6 version here: http://www.sfml-dev.org/tutorials/1.6/system-threads.php

SFML2 has some changes to the threading, making it (in my view) even easier, but the above tutorial is still useful.

 

Yes, as people have mentioned, multi-threading is a pain to debug and can take some time to wrap your head around it. But there's no clear point at which a programmer can be considered 'advanced' enough to start dealing with multithreading. In the end its just another tool, so as long as you're not discouraged by failure (we all fail when trying to do something, the point is to not give up), and don't mind banging your head against a wall (figuratively) for a while, then you could learn multithreading even as a beginner.

Share this post


Link to post
Share on other sites

does OpenGL handle multi-threading in the GPU for you when drawing?

 
The GPU is it's own hardware that runs independently of the main CPU, so yes, kindof. It's more then just "a different thread" though, since it's entirely different hardware, and your shaders will most likely be run as not only one, but a bunch of threads in parallell.

also is there any big difference in performance if you use multi threading for games, say for your update functions ?

The gain you get with multithreading depends on the problem you try to solve.
If the tasks you do in parallell has no dependencies on each other, you might get close to NumberOfThreads times the performance, but a game engine states is by its nature quite dependent on each other, having lots of requirements on what needs to be done before what, and is very tricky to multithread in an efficient way.

Short Answer: its impossible to tell in general. Edited by Olof Hedman

Share this post


Link to post
Share on other sites

I recommend boost::thread if you are comfortable with C++ STL.

 

If I tried to explain threading in one paragraph, I would say that your worker thread function is absolutely safe if it does not interact with outside world: does not read/write any variable except it's local ones. Of course, this would be useless. But once you have isolated your worker thread, you can begin serving it the tasks to do and receive finished work. This serving/receiving process is the main trouble of threading, but once you identify it, it is a matter of synchronization. The most basic synchronization mechanism is allowing only one thread read/write the serve/receive queue, and we call this mechanism locking, which at lower level is entering and exiting a critical section.

 

I think it is crucial for programmers to get familiar with threading, learn it and use it when appropriate, because modern applications and our CPU architecture really demands it nowadays. However, you better know exactly what you are doing, because threads are very confusing to debug for obvious reasons.

 

I did a quick glance over several recommended guides and this one seems to be quite good: http://www.paulbridger.com/race_conditions/.

Edited by Nercury

Share this post


Link to post
Share on other sites

What multithreading library would you recommend for C++? POSIX, boost?

I would say the most portable and general purpose way to go is C++11 threads + boost. C++11 is incomplete in providing high level threading tools. They put all the basics in, but not all of the high level structures built on top of them.

Unfortunately, beginner material using the two is probably gonna be hard to find. C++11 is too new.

Share this post


Link to post
Share on other sites

If the tasks you do in parallell has no dependencies on each other, you might get close to NumberOfThreads times the performance, but a game engine states is by its nature quite dependent on each other, having lots of requirements on what needs to be done before what, and is very tricky to multithread in an efficient way.

Slight nitpick: The speedup potential of parallel threads approaches the number of cores, not the number of threads.

Share this post


Link to post
Share on other sites

What multithreading library would you recommend for C++? POSIX, boost?

Learn them all (one at a time) and also WINAPI threads. They all do more or less the same thing. You'll probably want to prefer C++ threads, though, since it'll end up being the most portable. A typical thread lib doesn't really have an overwhelming number of components for you to learn. The problem is learning to use them in a sane fashion.

Share this post


Link to post
Share on other sites

If the tasks you do in parallell has no dependencies on each other, you might get close to NumberOfThreads times the performance, but a game engine states is by its nature quite dependent on each other, having lots of requirements on what needs to be done before what, and is very tricky to multithread in an efficient way.

Slight nitpick: The speedup potential of parallel threads approaches the number of cores, not the number of threads.

Annoying slight nitpick of nitpick: If task is CPU-bound.

Share this post


Link to post
Share on other sites

 

If the tasks you do in parallell has no dependencies on each other, you might get close to NumberOfThreads times the performance, but a game engine states is by its nature quite dependent on each other, having lots of requirements on what needs to be done before what, and is very tricky to multithread in an efficient way.

Slight nitpick: The speedup potential of parallel threads approaches the number of cores, not the number of threads.

Annoying slight nitpick of nitpick: If task is CPU-bound.

Supper annoying slight nitpick: or unless the task is superlinear, in which the speedup exceeds the number of cores.

Share this post


Link to post
Share on other sites



If the tasks you do in parallell has no dependencies on each other, you might get close to NumberOfThreads times the performance, but a game engine states is by its nature quite dependent on each other, having lots of requirements on what needs to be done before what, and is very tricky to multithread in an efficient way.

Slight nitpick: The speedup potential of parallel threads approaches the number of cores, not the number of threads.
Annoying slight nitpick of nitpick: If task is CPU-bound.
Supper annoying slight nitpick: or unless the task is superlinear, in which the speedup exceeds the number of cores.

Nitpick... annoying, etc: hyper-threading can give a speed up beyond the number of cores, due to hiding latencies.

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

Sign in to follow this