addy914Member Since 19 May 2010
Offline Last Active Sep 16 2012 12:49 PM
- Group Members
- Active Posts 43
- Profile Views 2,140
- Submitted Links 0
- Member Title Member
- Age Age Unknown
- Birthday Birthday Unknown
Posts I've Made
13 August 2012 - 10:04 AM
Threadpools aren't going to exactly help me. Since I planned on having the rendering thread in the threadpool structure, it does not help render any faster. The input thread shouldn't be too overhauled with work since it just takes data from the system. I doubt the network thread will be working too hard because it just takes packets and passes them to the form and usually those packets aren't doing any extraneous work. The content loading is probably the only thread that is working hard. But there is 4 threads, each one sits and waits for an event from a queue, and when it does, it will wake up and load it. That's it. If one is holding, then the rest will pick up. Yes, threadpools might be great for servers but I doubt it's for a client. It seems like its just not going to fit into my game. I doubt 8-cores is very common in computers. I'm sure if people have them, then lots of the time, they aren't actually using all 8 cores in one game.
I believe if I just used a threadpool and it would only have two threads(I have a duo core), then it would end up worse than what I have now. I would have to set a timer for network events and rendering. If all that is being processed on only one thread, and the other thread is for rendering with OpenGL, then it would get backed up, and my networking/rendering would get delayed and its just like a single-threaded thread all over again. I think having 7 threads would be fine with anything under 8-cores performance wise, because I have done this before and it works pretty smoothly(I used shared_ptr, so it's probably really slow to what it could be), and because the CPU will handle what thread is ran and when it is. Now, if you have 8 cores, you will most likely be running at maximum effeciency with this application, but anything more, you would run at the same performance. That is okay though, if it runs smooth, then who cares if it runs smooth again? I am having a set FPS, so whats the point if I enable it on more threads, it would just draw it the same.
Ill earlier in the topic stated that they got 50000 objects to successfully draw on one thread. With that statistic, I'm good with the way he did it. I doubt I will ever need to draw that many in my game. I believe he was drawing 3D objects, I plan to only do 2D in this game for now, so that number is probably increased.
Also, you have to account for the other processes being run on the computer. If someone has more than 8 cores(highly unlikely), then he probably has a lot of those being used as well. You don't want to be that one application that steals all of his cores and sky-rockets his CPU.
Ill, the example for a task you gave was a AI think step. I am working on a client that will connect to a server, the AI think step would be done through the server, which I agree servers would probably be perfect for threadpools. The case where AIs think step will be performed client-side, is in a single-player game. I agree that they should be ran concurrently and that will save time. I think if I were to make a single-player game, I probably would have my designated threads do what they are specialized for, and then have additional threads for the AI threads. I couldn't make the whole client have threadpools because their data would conflict. I get what you mean by a AIs think step, because it will just affect that AI and won't have to worry about synchronizing data. I would most likely assign a set amount of threads for tasks that should be performed concurrently if I ever was to work on a single-player game. That thread would just sleep until there was something in the queue to perform.
12 August 2012 - 09:55 PM
Thread pool will contain x threads where x is the number of cores. It has to be at least two. The first thread will be for rendering graphics. I will probably have some type of boolean to set to draw, not sure how yet. Then the other threads will read from tasks from a queue. I will have a timer set at a constant speed for checking network packets, and a timer for drawing graphics. Once the timer is hit, if its a network check, it will add a task to the queue to inform that it checks for data. If its a render hit, then it will set some sort of draw boolean. Now, the only confusing part is what exactly do I do when I get a task from the thread?
I am just imagining all this for now until I get a clear idea of how it will work. I don't want to just dive in programming yet
07 August 2012 - 09:08 PM
07 August 2012 - 11:04 AM
So, you're thinking more like a thread pool with x amount of threads that all take from a thread-safe queue and will perform a task when one enters the queue. That does sound like it'd work a lot better but I am using OpenGL which requires that the context be set in the thread. I could make a new context for each thread and set it there. I also have the question, how am I going to have variables per thread, if the threads will be running virtually any time of task?Don't think in terms of "threads". Use a framework that abstracts away threads.
in the input thread
Instead of having the X thread, Y thread and Z thread, it's much more efficient to run the X tasks across all threads, then the Y tasks across all threads, then the Z tasks across all threads. This makes 100% use out of a single-core machine, or a 24-core machine, whereas the "XYZ thread" system is hard-coded to best perform on a 3-core machine (and even then, certain cores will be much more over-worked than others).
Remember, in game engines, the point of using multiple threads is to take advantage of multiple CPU cores. If an operation isn't computationally complex enough to max out a single core, it doesn't need to be burdened with the complexity of multi-threading. Something like "collecting user input" definitely won't be complex enough to warrant having an entire thread dedicated to that single task (unless your user input device is a camera maybe, like the kinnect)!
Check out the "effective concurrency" series. The first one is here, and the last one has an index of them all.
I originally was going to use EnterCriticalSection but I don't like that 'if contention is low'. Contention would most likely be high in my application. Yeah, a lot of systems do have atomic operations for different variable types, but it just all depends upon the system. I am checking out future and promise now, they do sound interesting.
Windows CriticalSections and Linux futexes are usually the best option you have. If contention is low, they will burn a minimal number of CPU cycles (if no other thread is in the CriticalSection/futex, it's the price of a function call, then it will do a busy loop, repeatedly checking whether the CriticalSection/futex can be entered and only then will the thread be put to sleep (which is by comparison extremely expensive since it has to wait until the thread scheduler to allocate it another time slice when the CriticalSection/futex becomes free again).
I would recommend using std::mutex if you can (Visual Studio 2012 RC, GCC 4.6+). It's portable and provides its own RAII scopes (std::lock_guard).
There's also the possibility of writing lock-free data structures. These are mostly based on an operation called "compare and exchange" which all CPUs in the last 10 years have supported as an atomic operation (one that can't be preempted by another thread in the middle). There is a golden window of contention where lock-free data structures are much faster than CriticalSections/futexes - they're slightly slower at zero contention and tend to completely mess up under very high contention. They're also incredibly difficult to write even after years of experience with instruction reordering, cache lines and compiler behaviors. And they're a patent minefield.
Thread-local storage is the equivalent of copying your data to each thread. You seem to have one variable, but each thread reading or writing it is in fact reading a variable of its own. Sometimes useful, often confusing.
Smart pointers cannot help you with threading in any way. They cannot do any synchronization simply because when you call a method on the object the smart pointer is referencing, the smart pointer's function call operator will be invoked to return the address of the object. It could enter a CriticalSection/futex there, but there's no place where it could leave it again.
If a smart pointer is thread-safe, that means it won't blow up if you, for example, copy it while it's being destroying (a normal smart pointer, for example, grab the wrapped pointer, then increment the reference count - which might just have been decremented to zero between the two operations by another thread that is now destroying the object behind the wrapped pointer). Hint: Boost::shared_ptr and std::shared_ptr are not thread-safe. Boost's page on shared_ptr thread safety makes it sound a bit as if, but they're only saying that any number of threads can read the shared_ptr (dereference it) - which holds true for any C++ object - but a write (assigning, reference count adjustment) must never happen at the same time.
If you have the chance to use C++11 check out std::future to parallelize tasks in a simple way. Boost, Win32 and WinRT also offer thread pools (here's a small code snippet using the Win32 thread pool API: WindowsThreadPool.cpp) which are great of you can partition work into equal chunks (number of chunks = std::thread::hardware_concurrency ideally). Depending on the specific thread pool implementation, you can even do blocking tasks in those threads (the Windows thread pool will vastly overcommit the CPU based on some heuristics and it has a flag through which you can hint that you plan to block one of its threads for a longer time).
(Since no-one else has asked yet, I'll be "that guy").
Do you need multiple threads? Is your game going to be so processor intensive that it would cause slow-downs if you have multiple threads? Or do you just want to use multiple threads for fun?
A vast majority of hobbyist games don't need multiple-threads (I'd guess only ~5%, if that), and adding them just makes for more work and more problems. And, when you have a bug caused by race-condition/deadlock, you're going to have a helluva time debugging it.
I just wanted to make sure you were aware of this, and that you truly need to use threads.
Yeah, I could probably do without threads but I want to have them. If I use the message-passing style of thread-safety, then I won't have to worry about those since they will be accessing their own local set of variables. I don't mind doing the extra work/research to implement multiple-threads. Once I do get a working system of thread-safety, I will be able to use it in most of my applications. I also know when it is okay/not okay to use EnterCriticalSection and other such alternatives to thread-safety.
06 August 2012 - 11:39 PM
I am trying to imagine how this will fit in my game and a few issues come to mind. I draw my own textboxes, so I need to have a copy of the string there, I also need a copy in the input thread because when a button is clicked, I need that data from the textbox. I also am wondering about characters. I will need a copy of the characters to be drawn, but I will also need a copy in the network thread when walk packets and such are sent. This seems all a bit messy.