30 lines
1.9 KiB
Markdown
30 lines
1.9 KiB
Markdown
|
# Aliasing and the job system
|
||
|
|
|
||
|
|
Unity's job system infrastructure has some limitations on what can alias within a job struct:
|
||
|
|
|
||
|
|
* Structs attributed with [`[NativeContainer]`](https://docs.unity3d.com/ScriptReference/Unity.Collections.LowLevel.Unsafe.NativeContainerAttribute.html) (for example, [`NativeArray`](https://docs.unity3d.com/ScriptReference/Unity.Collections.NativeArray_1.html) and [`NativeSlice`](https://docs.unity3d.com/ScriptReference/Unity.Collections.NativeSlice_1.html)) that are members of a job struct don't alias.
|
||
|
|
* Job struct members with the [`[NativeDisableContainerSafetyRestriction]`](https://docs.unity3d.com/ScriptReference/Unity.Collections.LowLevel.Unsafe.NativeDisableContainerSafetyRestrictionAttribute.html) attribute can alias with other members. This is because this attribute explicitly opts in to this kind of aliasing.
|
||
|
|
* Pointers to structs attributed with `[NativeContainer]` can't appear in other structs attributed with `[NativeContainer]`. For example, you can't have a `NativeArray<NativeSlice<T>>`.
|
||
|
|
|
||
|
|
The following example job shows how these limitations work in practice:
|
||
|
|
|
||
|
|
```c#
|
||
|
|
[BurstCompile]
|
||
|
|
private struct MyJob : IJob
|
||
|
|
{
|
||
|
|
public NativeArray<float> a;
|
||
|
|
public NativeArray<float> b;
|
||
|
|
public NativeSlice<int> c;
|
||
|
|
|
||
|
|
[NativeDisableContainerSafetyRestriction]
|
||
|
|
public NativeArray<byte> d;
|
||
|
|
|
||
|
|
public void Execute() { ... }
|
||
|
|
}
|
||
|
|
```
|
||
|
|
|
||
|
|
* `a`, `b`, and `c` don't alias with each other.
|
||
|
|
* `d` can alias with `a`, `b`, or `c`.
|
||
|
|
|
||
|
|
>[!TIP]
|
||
|
|
>If you're used to working with C/C++'s [Type Based Alias Analysis (TBAA)](https://en.wikipedia.org/wiki/Alias_analysis#Type-based_alias_analysis), then you might assume that because `d` has a different type from `a`, `b`, or `c`, it shouldn't alias. However, in C#, pointers don't have any assumptions that pointing to a different type results in no aliasing. This is why `d` is assumed to alias with `a`, `b`, or `c`.
|