Why should I use Threads instead of Coroutines?

  • Unity has a functionality called Coroutines that can be a substitution for Threads in some cases.
Unity Coroutines use concurrency and Threads use parallelism.
The Unity API is not Thread-safe and you are allowed to create Threads without any practical limitations. Unfortunately however, the Unity API should be called from the main thread.

Why create threads when there are coroutines?

Coroutines have nothing to do with Threads. Coroutine methods can be executed piece by piece over time, but all processes are still done by a single main Thread. If a Coroutine attempts to execute time-consuming operation, the whole application freezes for the time being.

Threads are different. The execution of separate Threads is managed by the operating system (this actually depends on the .NET implementation). If you have more than one logical CPU, many threads are executed on different CPUs. Thanks to that, any expensive operation will not freeze your game, but it might slow it down a little.

When Threads are suboptimal, Coroutines may be preferable:

Creating a Thread is an expensive operation. If you use a Thread polling design pattern, you have to synchronize your computed data to the main thread. This is a very individual thing, so you have to consider this very carefully. It may even be necessary to perform some performance tests, because synchronization might be more expensive operation than computing your data in the main thread in the first place.

Threads are dangerous, so you have to be very careful when synchronizing things back! You also need to remember that Unity API is not Thread-safe, so all calls to Unity API should be done from the main Thread.
When threads are useful to use: 
When you are computing some expensive and/or long-term operations, Threads can still be useful. Examples of this are:
  • AI
  • Pathfinding
  • Network communication
  • Files operations 
More Information
Was this article helpful?
3 out of 3 found this helpful
Have more questions? Submit a request


  • 0

    here in this article the threads and the issues arising from the application of threading and synchronization has been dealt with clearly in the article, still many points are missing related to the coroutines which is the subject line. Still very very useful article.


  • 0
    Petr Sorfa

    Threads were not supported in Unity WebGL until 2019.1, and I'm not sure if that actually supports .NET threads. So that might also be a suggestion to use coroutines instead of threads.

    I've noticed that threads have different limitations on different platforms, i.e. the maximum number of threads differ on iOS compared to PC and MacOS, so its best to keep threads to a minimum.

    The thread implementation does not seem stable under stress (Network, CPU and memory), particularly under iOS where iOS sometimes simply terminates the app if thread activity is high. It could also be related to a memory leak, resource hogging or something like that. After several hours of use, an iOS threaded app may tank with no warning.

    Using .NET networking with threads work alright for light network requests, but it seems that using the Unity networking API (WWW, etc..) may be a better option.


Please sign in to leave a comment.