Sign in to follow this  

Future and promise suitable for games?

This topic is 1452 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

I've been playing around with the future and promise mechanism in C++11. I've previously used task-based multithreading systems, where a set number of threads pull tasks from a queue - and the tasks generally do a big chunk of work each.

 

I'm not convinced that futures and promises are particularly suitable for games, since they seem to be designed for smaller asynchronous tasks like I/O or handling UI events. Also, as far as I can tell, a new thread is allocated for each task which gets scheduled - which seems a little inefficient.

 

Wondering what everyone's take on this is?

 

Cheers!

Share this post


Link to post
Share on other sites
The concept itself is at least quite useful. There are plenty of cases where you need to wait for a particular series of tasks to finish, even if those tasks are batched to a large job system. They're very similar to any message system, albeit they only fire "once" and remember whether they've already fired or not.

Modern games also do a lot of request/response things to remote servers for DLC, friends list and status update, micro-transactions, etc. which is a great use of futures (or even async/await if it ever becomes widely available).

Remember, not every piece of code in a game is in some inner loop running thousands of times per frame.

The specific implementation of std::future may leave something to be desired. I don't know that there is much collective wisdom in the games industry to make a call on it one way or the other. A future can conceptually be tasked out to a thread pool; I don't know enough about the specific implementations of any to know if they are using a thread pool or not, however. You can write your own without much difficulty if you need to, however, and you could even replace std::future at a later date easily enough if you start writing code relying on it then later determine it has issues in its implementation.

Share this post


Link to post
Share on other sites

This topic is 1452 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