The job system works best when you use it with the Burst compiler. Because Burst doesn’t support managed objects, you need to use unmanaged types to access the data in jobs. You can do this with blittable types, or use Unity’s built-in
NativeContainer objects, which are a thread-safe C# wrapper for native memory.
NativeContainer objects also allow a job to access data shared with the main thread rather than working with a copy.
Unity.Collections namespace contains the following built-in
NativeArray: An unmanaged array which exposes a buffer of native memory to managed code
NativeSlice: Gets a subset of a
NativeArrayfrom a particular position to a certain length.
Note: The Collections package contains additional
NativeContainers. For a full list of the additional types, see the Collections documentation on Collection types.
By default, when a job has access to a
NativeContainer instance, it has both read and write access. This configuration can slow performance. This is because the job system doesn’t allow you to schedule a job that has write access to a
NativeContainer instance at the same time as another job that’s writing to it.
However, If a job doesn’t need to write to a
NativeContainer instance, you can mark the
NativeContainer with the
[ReadOnly] attribute, like so:
[ReadOnly] public NativeArray<int> input;
In the above example, you can execute the job at the same time as other jobs that also have read-only access to the first
When you create a
NativeContainerinstance, you must specify the memory allocation type that you need. The allocation type you use depends on how long you would like to keep the native container available for. This way you can tailor the allocation to get the best performance possible in each situation.
There are three Allocator types for
NativeContainer memory allocation and release. You must specify the appropriate one when instantiating a
Allocator.Temp: The fastest allocation. Use it for allocations with a lifespan of one frame or fewer. You can’t use
Tempto pass allocations to
NativeContainerinstances stored in a job’s member field.
Allocator.TempJob: A slower allocation than
Tempbut faster than
Persistent. Use it for thread-safe allocations within a lifespan of four frames. Important: You must
Disposeof this allocation type within four frames, or the console prints a warning, generated from the native code. Most small jobs use this allocation type.
Allocator.Persistent: The slowest allocation but can last as long as you need it to, and if necessary, throughout the application’s lifetime. It’s a wrapper for a direct call to
malloc. Longer jobs can use this NativeContainer allocation type. Don’t use
Persistentwhere performance is essential.
NativeArray<float> result = new NativeArray<float>(1, Allocator.TempJob);
Note: The number 1 in the example above indicates the size of the NativeArray. In this case, it has only one array element because it only stores one piece of data in its result.
The safety system is built into all
NativeContainer instances. It tracks what reads or writes to any
NativeContainer instance, and uses that information to enforce certain rules on the use of
NativeContainers that makes them behave in a deterministic way across multiple jobs and threads.
For example, if two independent scheduled jobs write to the same
NativeArray, this is unsafe because you can’t predict which job executes first. This means that you won’t know which of the jobs will overwrite data from the other. The safety system throws an exception with a clear error message that explains why and how to solve the problem, when you schedule the second job.
If you want to schedule two jobs that write to the same
NativeContainer instance, you can schedule the jobs with a dependency. The first job writes to the
NativeContainer, and once it has finished executing, the next job safely reads and writes to that same
NativeContainer. Introducing the dependency guarantees that the jobs always execute in a consistent order and that the resulting data in the
NativeContainer is deterministic.
The safety system allows multiple jobs to read from the same data in parallel.
These read and write restrictions also apply when accessing data from the main thread. For example, if you try to read the contents of a NativeContainer before the job that writes to it has completed, the safety system throws an error. Likewise, if you try to write to a NativeContainer while there are still pending jobs that read or write to it, then the safety system also throws an error.
Also, because NativeContainers don’t implement
ref return, you can’t directly change the contents of a
NativeContainer. For example,
nativeArray++; is the same as writing
var temp = nativeArray; temp++; which doesn’t update the value in
Instead, you must copy the data from the index into a local temporary copy, modify that copy, and save it back. For example:
MyStruct temp = myNativeArray[i]; temp.memberVariable = 0; myNativeArray[i] = temp;