I just started using the Unity Job System.

It has a lot of limitations. You have to use NativeArray with it and NativeArray doesn't allow many types, notably GameObject's. It says there is a bug that you have to use non-nullable types. Why can't the job system operate directly on game objects?


1 Answer 1


The Unity team explains this restriction in the documentation on The Safety System in the C# Job System as a way to avoid race conditions in multithreaded code:

The C# Job System solves this by sending each job a copy of the data it needs to operate on, rather than a reference to the data in the main thread. This copy isolates the data, which eliminates the race condition.

The way the C# Job System copies data means that a job can only access blittable data types. These types do not need conversion when passed between managed and native code.

The C# Job System can copy blittable types with memcpy and transfer the data between the managed and native parts of Unity. It uses memcpy to put data into native memory when scheduling jobs and gives the managed side access to that copy when executing jobs. For more information, see Scheduling jobs.

GameObjects are more complicated constructs, with different representations between the native & managed side (where the GameObject we use in C# is more like a handle, leading to its interesting behaviour around null / destruction)

We can't trivially copy a block of GameObjects out of the main game thread and then copy them back. For one thing, what if the object was destroyed or modified on the main thread in the meantime? References to the original GameObjects and their components wouldn't match up to the copies, so the whole thing gets pretty unwieldy to marshal back and forth to native code.

Instead, think about the logical transformations you need to perform on a group of GameObjects, and prepare a blittable data structure that contains the information needed for that transformation. Then you can use a job to perform the transformation, and upon completion, apply the results/conclusions back to your GameObjects.

  • \$\begingroup\$ This answer gets into the ballpark, but it's not quite on-target. Native containers can also be used for shared data that's not copied into a separate buffer for jobs, and instead has other in-editor checks to try to enforce safety. Because it's still a patch of unmanaged memory, many of the same restrictions on blittability apply, but for different reasons since we're not necessarily doing a bulk copy. I'm converting the answer to a community wiki so other users with more in-depth knowledge of the restrictions on native containers can clarify if they so choose. \$\endgroup\$
    – DMGregory
    Commented Oct 11, 2018 at 14:55

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .