koobas.hobune.stream
Associating NativeArray with a Job manually
I am running a job, which (for some reasons) accesses a NativeArray through a pointer. Therefore, the safety system is unaware of the job accessing the array, which is what I am trying to fix. Is there some intended way to achieve this? I was looking into AtomicSafetyHandle, but can't see anything relevant. I'd expect some method that tells the array/safety handle to disallow access until some JobHandle has completed.
Currently, I have an idea for a workaround, to schedule a separate dummy job (that claims the disputed array) and schedule it with a dependency on the unsafe job. Is this sufficient?
I am running a job, which (for some reasons) accesses a NativeArray through a pointer.
NativeArray is a pointer :T
A humble pointer in a fancy clothes.
I'd expect some method that tells the array/safety handle to disallow access until some JobHandle has completed.
This method exists - it's not part of the NativeArray/Unity.Collections but Unity.Jobs. It's Schedule ( JobHandle dependency ) which you mentioned.
Currently, I have an idea for a workaround, to schedule a separate dummy job (that claims the disputed array) and schedule it with a dependency on the unsafe job. Is this sufficient?
Dependency chain is confusing at first, but you will get the hang of it eventually.
You didn't describe the specific situation in great detail here but if by any chance you're scheduling the same job every frame and this job accesses the same NativeArray allocation then this job should include it's own job handle as dependency.
Thanks for the answer, though maybe I should rephrase the problem. My job does not have a NativeArray field, it has an IntPtr field. This field is a native pointer to the NativeArray's content. While it is true that it's just a fancy dress, it's this dress that provides the safety system with the right information about the array usage. Which is not provided in my case. Now you're going to ask "why", so I am going to tell you - I have a variable number of different arrays as a job input, and I can't have an array of arrays
It provides a warning system but not a scheduling system (seems similar but aren't). And this scheduling system is what you need. It's pointer type agnostic - whenever it's anit provides the safety system with the right information about the array usage.
IJob with
NativeArray or
unsafe pointer, doesn't matter, you just need to schedule the work with dependencies in order.
Think about it like this: every array can has it's ownI have a variable number of different arrays as a job input, and I can't have an array of arrays
JobHandle (stored in a hashmap/dictionary, for example). If you do that then you can combine them into a single one and here is your dependency for collision-free scheduling.
The main thing about native collections is that they provide warnings so the whole engine won't crash immediately on wrong ptr access (out of bounds). To manage pointer access in time we use
JobHadles.
Well... If I schedule one job that has a NativeArray field, it will prevent that array to be used in any job scheduled, unless the second job has the first job as a dependency. This is the safety system I am talking about. Now, my first job does NOT have a NativeArray field, but an unsafe pointer to its content, which means that the safety system does NOT know about the job's RW access to this array, and does NOT prevent other jobs from being scheduled without a dependency to this job. I need to somehow tell the safety system about the job's RW access to the array, other than the standard reflection-based automatic detection. I assume that, using reflection, the job struct is inspected for NativeContainer fields, and, optionally moderated by the [ReadOnly] and [WriteOnly] attributes, links the array to the job, and I assume that this safety functionality is controlled by the AtomicSafetyHandle. I am looking for a workaround, since the reflection-based system can't detect the NativeArray access in the job (because I am only using IntPtr or unsafe pointer) and can't prevent non-dependent jobs from accessing the array during scheduling.
