multithreading c++
Author
Hi I have made a fps-game and am getting errors. I don't really know what is causing the errors but i belive that I am writing to an uninitialized pointer.
I believe that it is caused by a part of the engine that uses multiple threads because the error dissapears when I make that part use the main thread. I don't really know how to do multithreading but it has worked until know.
I am starting a thread with:
CreateThread(NULL,0,getpath,gpdata,0,NULL);
I use a mutex for some data that is used by all threads.
Is there anything special to think about when using multiple threads?
I know mutexes has to be used when multiple threads use the same variabes.
There is actually plenty to think about when using multiple threads!
Writing concurrent applications is orders of magnitude more complex than writing sequential applications. It may not seem that way at first, but try proving that your concurrent application is correct and you'll see what I mean.
Of course that doesn't mean you shouldn't use multi-threading, you should just be aware that it is very complex (at least shared-memory concurrency is).
I can't tell you what's wrong with your game without seeing any code, but I'd recommend that you buy yourself a book on concurrency and study it before diving any further into it.
My suggestion to you: until you've fully grasped concurrency, create threads that operate in complete isolation (no shared state). That way, it will be very easy to reason about them and you won't need to lock (= no deadlocks but also no race conditions).
Writing concurrent applications is orders of magnitude more complex than writing sequential applications. It may not seem that way at first, but try proving that your concurrent application is correct and you'll see what I mean.
Of course that doesn't mean you shouldn't use multi-threading, you should just be aware that it is very complex (at least shared-memory concurrency is).
I can't tell you what's wrong with your game without seeing any code, but I'd recommend that you buy yourself a book on concurrency and study it before diving any further into it.
My suggestion to you: until you've fully grasped concurrency, create threads that operate in complete isolation (no shared state). That way, it will be very easy to reason about them and you won't need to lock (= no deadlocks but also no race conditions).
Quote:Original post by glPetter3f
Hi I have made a fps-game and am getting errors. I don't really know what is causing the errors but i belive that I am writing to an uninitialized pointer.
What errors are you getting specifically? And what leads you to believe an uninitialiszd pointer is at fault?
Without this information, it is very hard for people that might have more experience in this area to help you diagnose your problem.
Author
http://www.gamedev.net/community/forums/topic.asp?topic_id=491382
I don't want help to fix the problem just know if there is anything special to be avare of when multitreading.
I don't want help to fix the problem just know if there is anything special to be avare of when multitreading.
Quote:Original post by glPetter3f
http://www.gamedev.net/community/forums/topic.asp?topic_id=491382
I don't want help to fix the problem just know if there is anything special to be avare of when multitreading.
If you're having to ask this question then it might be best to keep things single threaded until you're better read on the subject. Multithreaded programming is a very different beast.
If you are tempted to keep using threads, look to using higher level abstractions and libraries where possible rather than dealing with OS-level APIs.
Author
Do you know off any "high level" multithreading library? I really need multithreading because so many people have multicore cpu's nowadays and if i can make my program run twice as fast there is no forgiving to not do it.
First, are you absolutely sure your program will really use all the CPU power you can throw at it? I mean if a game runs at 400 frames-per-second on a single core, there's probably not a lot of point in adding the complexity of threading. The experts producing next-gen games have quite enough trouble occupying all the cores on modern consoles and PCs.
It's also telling that you said "twice as fast". It wouldn't surprise me if desktop with 8 cores are common place in a couple of years. Maybe you need to consider N cores, rather than just 2?
This is where libraries and frameworks and other tools come in. For instance, look up OpenMP, Intel's Threading Building Blocks (TBB) and constructs such as thread pools, task queues and futures.
If you need finer grained control over threads, you probably don't want to use something as low level as the Win32 functions. The Boost.Thread library is well designed and provides a much easier interface to work with.
But again, be absolutely sure that you need threads before using them. The designs of classes, algorithms and other constructs will vary wildly depending on whether you plan to use threads or not.
It's also telling that you said "twice as fast". It wouldn't surprise me if desktop with 8 cores are common place in a couple of years. Maybe you need to consider N cores, rather than just 2?
This is where libraries and frameworks and other tools come in. For instance, look up OpenMP, Intel's Threading Building Blocks (TBB) and constructs such as thread pools, task queues and futures.
If you need finer grained control over threads, you probably don't want to use something as low level as the Win32 functions. The Boost.Thread library is well designed and provides a much easier interface to work with.
But again, be absolutely sure that you need threads before using them. The designs of classes, algorithms and other constructs will vary wildly depending on whether you plan to use threads or not.
Quote:I really need multithreading because so many people have multicore cpu's nowadays and if i can make my program run twice as fast there is no forgiving to not do it.You don't know what you're doing, so it's unlikely you'll get your multithreaded version to run correctly at all, let alone faster than your single threaded version.
Threading is not magic dust you sprinkle on code to make it go faster. Unless you know what you're doing AND your problem has a structure that paralellizes, threading will not help.
Author
I have actually used multithreading a couple of times and I can't understand how it can be a problem to get enaugh job to occupie all the cores. Almost all problems in games can be pararellized. I have discovered that the problem I thought was caused by the multithreaded part of my program still exists without multithreading so i guess i have done it right anyway. The programs i have made using multiple threads has actually been running with 100% cpu and almost twice as fast as with one thread (2 cores).
Quote:Original post by glPetter3f
I have actually used multithreading a couple of times and I can't understand how it can be a problem to get enaugh job to occupie all the cores.
Well if the game is simple and the code is efficient, there will be no benefit.
Quote:Almost all problems in games can be pararellized.
Where on earth did you get this idea from? If you have a genuine reference, I'd be very interested in hearing it. Parallelisation isn't the same as using two threads. It's true that a lot of algorithms have parallel counterparts, but games have lots of sticky interactions that are typically hard to parallelise in the general sense (to N cores).
Quote:The programs i have made using multiple threads has actually been running with 100% cpu and almost twice as fast as with one thread (2 cores).
This is the wrong way to benchmark multi-threaded programs. You need to compare your parallel algorithms against the fastest single threaded algorithm available, not your multi-threaded code running on a single core.
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement
