I see what you mean now, it does sound efficient. i think I am confused on what your definition of a 'task' is? Can you elaborate and maybe give an example of what a task is?

A task could be an AI character's think step. If you have like 50 AI characters who need to think during the current game update, have them all run concurrently instead of serially.

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.

I seem to be having trouble picturing how I will achieve threadpools. I'm not sure how to synchronize the data still. If I have a thread pool(decided I will dedicate the first thread to rendering at a constant FPS), and then have the other threads reading tasks from a queue and running them, what if two network packets come in and access the same data? I'm a bit confused on how I should store data. You mentioned that the 'task' should contain the data it needs already? I am a bit confused, but I will show what I am thinking of doing.

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

Honestly, I think I will stick with having my 7 threads that each do their own task. I do like the idea of passing data and each thing having their own copy, that is very good. It may take a small bit of extra memory, but that will make up for the faster processing.

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.