Sign in to follow this  

Multiple Threads Vs Thread Pool

This topic is 2793 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

If I have 12 mobile units querying my pathfinding engine simultaneously, Should I use 12 independent threads, one for each unit, or Use a thread pool instead. Both have drawbacks, If I use 12 threads, the application won't be so responsive. If I use a thread pool, some units will not be able to move while it is in the queue. What is your opinion? Thanks Jack

Share this post


Link to post
Share on other sites
If you take one step backwards, the problem is that some computations take longer than a frame to complete (e.g. pathfinding). Your solution is to move these computations onto a thread/thread-pool.

There's no need to use threads or thread-pools for this, if you go back and solve the initial problem in a different way - such as re-designing the pathfinding code so that it can stop after performing some of the computation and then be resumed next frame.

Share this post


Link to post
Share on other sites
Quote:
If I use 12 threads, the application won't be so responsive.
IMHO there wouldn't be any issues with that amount of threads, because OS takes care of them very well [dispatching]. Take a look at windows task manager, even wmplayer.exe has about 20 threads and that's pretty resposive.

Share this post


Link to post
Share on other sites
@siavash

Your analysis contains a flaw. 20 threads can be very responsive if they are all blocked waiting for something to happen. But if we are talking about 20 runnable threads all vying for processor time, then responsiveness is going to suffer.

@lucky6969b

Use a small thread pool. You generally don't want many more active threads than you have logical processors. Another consideration for responsiveness is to cap the total processor time doing pathfinding relative to the rest of your program.

For example, if you make it so that your pathfinding algorithm can be suspended and restored, then you can give the pathfinder X milliseconds to work with every frame, and once it reaches its allocated time it saves state and pauses, allowing other tasks to run. You can also have a queue of pathfinding tasks, so that you don't end up in the situation of trying to process hundreds or thousands of tasks in some small time segment, with none of them really making progress.

On the other hand, have you profiled how many units are making pathfinding requests on average, and how long these tasks take to complete? The more information you have here the better you can design a system that meets your pathfinding latency and bandwith requirements.

Share this post


Link to post
Share on other sites
Quote:
Original post by rip-off
@siavash

Your analysis contains a flaw. 20 threads can be very responsive if they are all blocked waiting for something to happen. But if we are talking about 20 runnable threads all vying for processor time, then responsiveness is going to suffer.

@lucky6969b

Use a small thread pool. You generally don't want many more active threads than you have logical processors. Another consideration for responsiveness is to cap the total processor time doing pathfinding relative to the rest of your program.

For example, if you make it so that your pathfinding algorithm can be suspended and restored, then you can give the pathfinder X milliseconds to work with every frame, and once it reaches its allocated time it saves state and pauses, allowing other tasks to run. You can also have a queue of pathfinding tasks, so that you don't end up in the situation of trying to process hundreds or thousands of tasks in some small time segment, with none of them really making progress.

On the other hand, have you profiled how many units are making pathfinding requests on average, and how long these tasks take to complete? The more information you have here the better you can design a system that meets your pathfinding latency and bandwith requirements.

Hi rip-off,
Enter 8920140.000000
... do work
Leave 8920182.000000 Time Used: 42.000000

The app spends about 1 to several hundred milli seconds per iteration on p.f..
I wonder I need to re-design my code, but my algorithm is good for dynamic pathfinding since it is incremental in nature... it seems to be very slow when spawning 12 threads at the same time though.... or could you provide some good references/links for this? (especially for the stop and restart thing)
Thanks
Jack

Share this post


Link to post
Share on other sites

This topic is 2793 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

Sign in to follow this