Jump to content
  • Advertisement
Sign in to follow this  
noatom

Repeatedly using Async

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

Here's my question: if about 30-60 times a second I receive new data that needs to be processed, does it even make sense to consider using async with a future?

A future, when called, always has to return. So using a future means the launched thread will always close. Repeatedly using futures would mean repeatedly creating/closing threads those 30-60 times a second.

Is anything of what I wrote above wrong? Or it's true, and I should use a raw thread for this scenario. If it would be true, it'd mean any sort of task that requires repeatedly calculating data in a short inverval, would be better off on a raw thread.

Share this post


Link to post
Share on other sites
Advertisement

For network stuff, I always create a separate thread where the only purpose is to receive packets (in a blocking manner) and then pushing them into a queue.  Then on the main thread in the update method, I will loop through the queue and process them all.  That means you need to protect that queue with a mutex though.

Share this post


Link to post
Share on other sites

Repeated processing by itself is not a reason, but it sounds like that isn't your case.

Trying to run a reliable scheduling system might be a reason if there are other things in the thread that make timings difficult.  You'll need something to run reliably, although it doesn't necessarily need to be your own threads that you control.  

Some tasks take time outside your control, including I/O like disk manipulations, network transmission, and hardware communications like rendering or buffer transfers. Some of those are designed to wait around, also called 'blocking' operations. Generally there are alternate forms that use threading or similar systems behind your back, called 'asynchronous' or just 'async' operations. When the OS provides the operation it may not require any threading.

 

C++ futures might be a way to go, but they are not the only options. Thread pools, user-managed work schedulers, fibers and co-processes, and OS-provided async calls with callbacks might also work for you.

Share this post


Link to post
Share on other sites

On a network IO system there would be methods to handle message events async from the OS layer so for example IOCP on Windows and similar setups on Linux/Android. Using these would create an async return from a message receive so you could for example set an event into your system and go on waiting for the next network interrupt.

Setting up such a system I would create an own message pipe for network events and let my whatever thread/task spread that messages to recipients whenever needed but that depends totally on the system you use so take this as general idea

Share this post


Link to post
Share on other sites

If it would be true, it'd mean any sort of task that requires repeatedly calculating data in a short inverval, would be better off on a raw thread.

 

Totally true. Generally - if you can, don't spawn threads for short/repeat/high-frequency tasks - use long(er)-lived thread(s) with queues for that. 

Share this post


Link to post
Share on other sites
Sign in to follow this  

  • Advertisement
×

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

We are the game development community.

Whether you are an indie, hobbyist, AAA developer, or just trying to learn, GameDev.net is the place for you to learn, share, and connect with the games industry. Learn more About Us or sign up!

Sign me up!