Search Unity

2018.1 Beta Unity.Jobs and Unity.Collections Hot Tips

Discussion in 'Entity Component System' started by OswaldHurlem, Feb 14, 2018.

  1. OswaldHurlem

    OswaldHurlem

    Joined:
    Jan 6, 2017
    Posts:
    40
    Here's some things I've learned about Unity.Jobs and Unity.Collections which I consider to be important or useful. Please add your own.
    • You can only .Schedule() or .Run() jobs from the main thread.
    • For an IJob, .Run() runs a job from the main thread and seems to be mostly identical to calling .Execute(). However, if you do something you can't do off the main thread (accessing GameObjects, scheduling jobs), Unity will give an error. This is useful for debugging, as it can provide you with thread safety checks without actually running multiple threads and increasing likelihood of a crash.
    • default(JobHandle) is a valid way to express a non-existent handle.
    • You can (but probably shouldn't) create a temporary NativeArray which points to the contents of a managed array. See code.
     
    Last edited: Feb 14, 2018
    OswaldHurlem, Feb 14, 2018
    #1
    mathias234, Flurgle and LeonhardP like this.

  2. OswaldHurlem

    OswaldHurlem

    Joined:
    Jan 6, 2017
    Posts:
    40
    • You can make a zero-length NativeArray and you WILL be expected to Dispose it.
    • One strange thing about scripts in the Unity Editor is that static variables can be GC'd and the program will continue running. To avoid an error with static NativeArrays and a few other disposal-enforcing classes like ComputeBuffer, make a StaticDispose function which gets called by some component's OnDestroy() function.
     
    OswaldHurlem, Feb 21, 2018
    #2
    mathias234 likes this.

  3. Joachim_Ante

    Joachim_Ante

    Unity Technologies

    Joined:
    Mar 16, 2005
    Posts:
    5,203
    You should never do any static variables in multithreaded code. Full Stop. End of story.

    The only thing it does is result in code that will eventually crash when someone else starts refactoring or probably as soon as you write it. Its brittle. Writing multithreaded code is hard when you don't follow strict rules.

    If this wasn't enough, we will at a later point (Not in 18.1) Ship extensions to the C# compiler which will give you compile errors when accessing global variables from a job using static analysis.

    There are good and bad patterns with multithreading. Years of real world experience from a lot of devs shipping games, these are pretty well known and for the good of humanity we are just going to enforce them. (And yes we will probably have an attribute to turn them off on a per variable basis - in Unity.Collections.LowLevel.Unsafe to make it crystal clear that you do NOT want to do that...)

    But the point is that there is very very very rare situations where using a static variable in jobified code is the right choice.

    In fact in all of unity, > 1M lines of code. We have zero places where jobified C++ code uses very few static variables for justified reasons.

    And every single place that does, does so for bad reasons based on how the code has been developed over time and us just not being as experience several years ago. I seriously can't think of a single reason to ever do it...

    This is a very clear case of, its just wrong, don't do it.
     
    Joachim_Ante, Feb 21, 2018
    #3
    recursive, Nozynski, OswaldHurlem and 1 other person like this.