Job clean up in main thread (locking the job start up required?)

[tough holly]

Hi, say theres some pre-job clean up that has to happen that depends on managed types (so it can't be done inside the job). You don't want to do the clean up while dependent jobs are running so you Complete(); but then while you are doing the clean up (in the main thread) it's possible for a scheduled job to start mid-way that modifies the same NativeArray for example. So first question challenges the premise: is it possible for a job that was scheduled earlier in the main thread, to start up later on in the main thread between a .Complete() of the job in question, and where you start to clean up the values passed to it?

If so, second question: can you lock any scheduled jobs from starting for a short window of time?

I have attached a screenshot of what I'm talking about. Specifically where I call for the targetFence handle to complete (any job that modifies targetDistances sets this handle) and then clear the array right after.

[timber seal]

I think it will be better for your sanity later on if you have a defined set of points in the Update Loop where you run specific functions. Your objects must apprehend those points too, similar to how ECS governs its systems and job chain.

it's possible for a scheduled job to start mid-way that modifies the same NativeArray for example
So nothing will ever spontaneously start up in the middle of something such as this case.

For example, when you are already at the point of "cleaning up", jobs should already be completed, and no job-scheduling logic should have any chance to run.

[coarse kraken]

To answer your questions directly:

• a long as your jobs are in the dependency chain, it's not possible for them to start after a Complete() of that chain. It waits for the dependencies in its entirety, and launches the threads if they aren't working yet
• you cannot prevent jobs from starting after scheduling them. You should just schedule them later in that case

When I do this outside of ECS I tend to keep separate JobHandles for reading and writing of certain data/systems

E.g. a particle system job will have a ParticlesReadDependency and ParticlesWriteDependency: the particle modification jobs use the write dependency, the rest uses the read dependency. The read jobhandle of course has the write jobs as a dependency (after scheduling the write jobs, it's effectively the same)

Then, as long as you respect the read/write, things work, and it becomes a matter of ordering correctly, as Grean Leaf says.