Search Unity

  1. The Unity Pro & Visual Studio Professional Bundle gives you the tools you need to develop faster & collaborate more efficiently. Learn more.
    Dismiss Notice
  2. Want more efficiency in your development work? Sign up to receive weekly tech and creative know-how from Unity experts.
    Dismiss Notice
  3. Participate with students all over the world and build projects to teach people. Join now!
    Dismiss Notice
  4. Build games and experiences that can load instantly and without install. Explore the Project Tiny Preview today!
    Dismiss Notice
  5. Improve your Unity skills with a certified instructor in a private, interactive classroom. Watch the overview now.
    Dismiss Notice
  6. Want to see the most recent patch releases? Take a peek at the patch release page.
    Dismiss Notice

Coroutines and the Unity C# Job System?

Discussion in 'Entity Component System and C# Job system' started by neounix, Jun 24, 2018.

  1. neounix


    Jan 9, 2017

    Sorry for being so ignorant (and frustrated) about this; but I really want to take advantage of multi-core computing by using my existing thousands of lines of Unity MonoBehaviour code.

    Is it possible to use the Unity C# Job system to simply submit / direct a Coroutine() to run on it's on thread in a multi-core machine to Instantiate() MonoBehaviour game objects?

    Also, similar question for Unity Coroutines in general? Can we simply use the Unity C# job system to submit any general Coroutine() to be executed on different cores in a multi-core device?

    Maybe it better I forget about Unity Jobs and ECS and just use the C# native:

    Code (CSharp):
    1. using System.Threading;
    Last edited: Jun 24, 2018
  2. recursive


    Jul 12, 2012
    Unfortunately, in order to take advantage of the new jobs system, you'll have to rewrite the data you send to the jobs so that only blittable data types are passed to the job and NativeContainers. The Job system is completely divorced from the coroutine system. You cannot access reference types nor safely call most static functions if they access the normal Unity APIs on a Job, the limited subset is what enables the heavy optimizations.

    Even if you were to use System.Threading, most Unity object types and APIs are not thread-safe regardless, so you'd still need to restructure how you're setting up your data, usually by creating a copy (or reusing a buffer) of what needs to be processed, hand it over to threading land, and only read it back on the main thread after the worker notifies completion or pushes stuff into a shared queue (works but very inefficient).

    If you still want a thread-able API that's closer to what you may have dealt with in coroutines, that allows you to wrap or replace them, you may want to look into the UniRx framework as it has some nice utilities to deal with corutines and it's easy to thread logic and manipulate reference types on a thread. It's still not safe to access Unity's APIs or access most Unity Objects while running thread logic but it's miles away better than dealing with low-level System.Thread(s) and managing communication queues yourself. It's has tools to have logic that runs on a thread, then swaps to a coroutine or vice versa.
    neounix likes this.