Threading vs task pool

Creating a thread means creating a parallel control flow which requires a stack and additional cpu-time to switch to/from this thread.

Another problem with threads is synchronization. If more than one thread works on the same data at the same time, this can become quite difficult.

And doing things in parallel does not necessarily mean they are done faster.

Quote:

Original post by nmi Creating a thread means creating a parallel control flow which requires a stack and additional cpu-time to switch to/from this thread. Another problem with threads is synchronization. If more than one thread works on the same data at the same time, this can become quite difficult. And doing things in parallel does not necessarily mean they are done faster.

I know what threading is and how it works :P.

What I meant is, if you've got a bunch of tasks which all have an Update() method which you call once every cycle, each of them in sequence, isn't that simulating exactly what threading does anyway? Regardless of the overhead involved in switching threads, wouldn't it still be faster than doing it the other way?

I'm not so sure that access control is a huge problem, either - if one task-thread is blocked waiting to acquire another task-thread's mutex then it would still be accessing the data more often than ordinary sequential processing. And with proper acessors I don't think it would be that difficult to code.

I personally use both: Rendering, Input, Audio all have an update function and they are all called in the main loop. I also have a music thread which loads and plays ogg files which runs in a thread and has a player like interface.

Quote:

Original post by SoulSkorpion What I meant is, if you've got a bunch of tasks which all have an Update() method which you call once every cycle, each of them in sequence, isn't that simulating exactly what threading does anyway? Regardless of the overhead involved in switching threads, wouldn't it still be faster than doing it the other way?

One cycle is done when the Update() function is called on each object. No matter if you run the Update() functions one by one or in parallel, the same amount of work has to be done.

With threads you have the overhead of task switching, but you may gain some performance when having a multiprocessor system and you create as many threads as you have processors. (e.g. P4 with hyperthreading)

However if those Update() functions work on shared data, I don't think you will increase speed overall.

Doing as Ilici suggested is the right thing use for threads.

Do NOT use threading for in-game-tasks that use the same set of data (ie: world data).
Imagine this, you have a task that does your graphics, and a task that does your game logic. Put these in two seperate threads.
Now, what happens if your graphics task is drawing a huge game object to the screen... at that same moment your game task decides that the object is not needed anymore and deletes the object. BANG! Crash.
Now, this is a simple example that causes an obvious fault.



Now, I could tell you that you should lock shared resources with mutexes and that the overhead of threading (not only OS overhead) can minimise the performance advantage, but I'll put this rather simple:
Using that many threads will be a lot more work.
Probably more work than it's worth.



Imagine you have half a dozen threads... and each one of those is updating objects... change a float here, change a float there. Delete this, delete that. You need to account for all of that.
Plus multi threaded applications are tediously tough to debug I have discovered with my peer-to-peer project.
I rather avoid them if I have a large and complex shared dataset.

As I said, access control is not an issue if nothing can delete a value without going through a mutator, and the object contains mutexes.

That aside, thanks for the advice everyone. So basically there's no real advantage to be gained unless it's running on a multiprocessor machine? (or a particularly long processing task or whatever).

[Edited by - SoulSkorpion on November 19, 2004 2:31:23 AM]

That example with the deletion issues was kinda lame. An easy solution would be to use reference counting to prevent premature resource deallocation.

Spinning a thread for every task would really be a bit insane. Maybe if a seperate thread was spinning to process tasks or something so that major subsystems were running in parallel... there might be some benefit. But like other's said, with so many threads, the cost of thread setup would be crazy.