C++ Thread safety
Members - Reputation: 226
Posted 09 August 2012 - 04:21 AM
This is really easy with intel thread building blocks or OpenMP as I mentioned before. Also Intel TBB comes with a lot of threadsafe and efficient data structures and other things that you'd want to use.
I'd recommend you don't even think about writing things like lockless queues yourself. There's a lot to think about, such as cache bounds, atomics, etc... Use Intel TBB's structures.
Members - Reputation: 158
Posted 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
Members - Reputation: 427
Posted 13 August 2012 - 08:24 AM
Limiting the scope and amount of the shared data is a necessity, and even then, it's not a particularly easy problem, determining how to best create work units. It's not a science, as much as it is just empirical testing on your part and with your particular engine.
I hate to answer "How do I do X?" with "Don't do X." But the most important thing to ask yourself is "Do I NEED multithreading?" You probably don't. Not that you shouldn't adhere to best practices throughout your code so that it's at least a possibility in the future, without too much pain, but you don't need to multithread until performance on a single thread becomes a real problem.
Members - Reputation: 158
Posted 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.
Edited by addy914, 13 August 2012 - 11:11 AM.