Unity Burst and Jobs: Design Dependencies Around Shared Native Data

Separate compilation from scheduling

Burst supports a restricted subset of C# suitable for native compilation; the Job System schedules work and its dependencies. Adding [BurstCompile] does not define the order in which separate jobs may touch shared data. Design the data flow first, then make the computation compatible with Burst's supported types. This article uses the cited Unity 6.0 and Burst 1.8 documentation contracts. [1][3]

Declare access to the allocation

A NativeArray<T> provides access to native memory. Copies of its container value refer to the same underlying allocation, so passing the container into several jobs does not give each job an independent result buffer. [2][3]

Mark a job field [ReadOnly] when that job only reads it. Multiple readers can then share the input without falsely declaring write access. A producer writing an array and a consumer reading it need an explicit dependency. The main thread must also respect pending access; it is not exempt from the container's safety rules. [2]

Build an illustrative buoy calculation

Suppose a scene has 256 buoys. Prepare their positions as input data. A wave-sampling job writes a height array, while an independent wind-sampling job writes a wind array. Both can read the position array; neither producer should overwrite the other's output.

Combine their handles with JobHandle.CombineDependencies, then pass the combined handle when scheduling a force-calculation job that reads both results. The combination means that the consumer waits for both producers. It does not force the producers to execute simultaneously, and their scheduling order alone would not establish the required dependency. These names and the buoy count describe a proposed project design. [3]

Choose the main-thread handover

Retain the final job's handle. Call Complete before the main thread reads its result buffer, then apply the resulting scene changes from the main thread. Completing that dependent job also completes the dependencies required for its result. [3]

Place this handover where the result is actually needed. Immediately completing every producer removes opportunities to overlap useful work. Keep container ownership visible during cancellation or scene teardown as well: finish outstanding access before freeing the allocation with Dispose. Choose an allocator whose documented lifetime fits how long the buffer remains in use. [2][3]

Check the boundary and measure the workload

Ordinary managed object graphs are outside Burst's supported data model. Prepare suitable value data and native containers instead of passing scene-object references into the numerical kernel. Consult the type reference for specific exceptions and restrictions; support is more precise than a blanket statement that every C# construct works. [1]

Review the buoy pipeline for missing dependencies, accidental writes, early completion, and repeated allocation. Measure scheduling overhead, computation, and the main-thread wait on the target device. A valid dependency graph establishes safe ordering; it does not promise a speedup for small workloads.

Sources

1. C# type support — Burst 1.8 — Unity Technologies.
2. Introduction to NativeContainer — Unity Technologies.
3. Job dependencies — Unity Technologies.