Do jobs resolve automatically dependencies according the native containers used?

I think I know the answer about this, however I want to double check:

if I got it right, entity related jobs are able to optimize and batch properly the job according which entities are read and written. This should mean that even if I combine jobs using the inputDeps, the ECS code is able to batch the jobs in such a way there should be an optimal execution of jobs and they don't just run in sequence. It may not be really like that (didn't test it much), in case a more exhaustive explanation is appreciated.

However when jobs are not used in the ECS context, I think native containers help only in warning when they are used in a not multithread safe, without actually sorting the jobs using them. Is this correct?

 

there are 2 concepts here:

job system: jobs are scheduled according to the dependencies you pass (e.g.

jobA.Schesule(jobBHandle)

means job a is run after job b). the safety system ensures that if you pass the same non-readonly data to 2 jobs and you don't declare dependencies, an error is raised

ecs: each JobComponentSystem calculates the dependencies of the next system based on its queries

result: you need to schedule jobs in a JCS passing the

inputDeps

(and returning the resulting handle) if you only access component data (chunks)
if you are using additional native containers and you share those between system, you need to manually track the dependencies of the related jobs too.

example:

EntityCommandBuffer

when using ECBs, you share a native container (the ecb itself) between your system and the barrier, then you schedule a job with it. you need to use

AddJobHandleForProducer(...)

to tell the barrier that it should wait your job

 

thanks a lot @M_R, it helped!

 

BTW I inject another question since you mentioned it. AddJobHandleForProducer allows to use the ECB inside another job without needing to complete it immediately. I guess there isn't a similar mechanism for
BeginExclusiveEntityTransaction. All the examples I found seem to need to complete the job before call the EndExclusiveEntityTransaction

 

ECB is made for that exact purpose: allowing structural changes inside jobs (they are deferred until the barrier updates)
ExclusiveEntityTransaction locks the entire entity manager to be used inside a single other thread, and is used for e.g. loading subscenes.
you cannot use the EM in the main thread during an EET.

EET is used by e.g.

SubSceneStreamingSystem

to load stuff into other worlds, then it moves the data to the main world.

basically you create a new world, start an EET from its EM, then schedule a job.
you don't Complete() immediately, but wait until it IsCompleted (by polling in an Update loop)
you don't touch that world until it is ready.
then you complete the job, end the EET, and use the world in main thread

 

Here is what @M_R described. Old ugly sample for some post on forum, I don’t remember for whom I wrote it.

 

wasn't all this stuff supposed to be simple

@Eizer_Zeng what is the use case for your code?

 

I’m @eizenhorn.
It’s just sample how we can create huge amount of entities on other thread, without stalling main thread. It’s just fast written sample, of course it can be beautified.