Can system execute same job multiple times, before this job is finished?

[Antypodish]

This question is somehow related to my previous thread
** How stable is actually determinism for busy systems? **
But decided to keep it separate.

So question:
Can system execute same job multiple times, before this job is finished?

Lets say, I got system with a job, which creates n entities.
It requires 2 to 4 frames to execute.
For this particular scenario, I call this system manually every frame.
Meaning I call job every frame.
Would that mean, I create n set of entities multiple times?

If so, that may be potentially problematic, when EntityCommandBuffer is involved.

If that is the case, any thoughts how to prevent multiple system/jobs calls?

Update:
See proposed solution

@Antypodish

Regarding main thread, I have came up with following solution.
Not sure if is right, surely is not most elegant, and I believe, it can cause potentially lots of other issues, when comes to ordering systems. But could not find best alternative so far and yet it works for me, for accelerated fixed time, of up to x10.

Before going into it however, I just put reference to other thread that I asked relevant question,
** Can system execute same job multiple times, before this job is finished? **
You can skip quotation.

I asked

Resposne back

Proposed and in test solution

So my result of testing, as @tertle concluded, that jobs which runs longer than target frame rate, can potentially create duplicated data.

In pursue of seeking for the solution, I came with following:

• Involved systems relies on EntityCommandBuffer, creation of entiteis and relevant component tags, which activates GetEntityQuery groups in next systems. Details not discussed here.

• Using for systems creation

mySystem = World.Active.GetOrCreateSystem <MySystem> () ;

• In this particular scenarion, I have decided not to use

systemGroup.AddSystemToUpdateList ( mySystem ) ;

• To define strict order, I use mySystem.Update () ; in private void FixedUpdate () loop

• Each system has [DisableAutoCreation] attribute. No other attributes.

• In my case, I use switch, to control step of the period, in which relevant systems are executed sequentially. All works nicely, when x1 speed is running.
  In case of x5 and more, jobs start loosing sync, hence next step is required.

• First I check, if system is ready to update
  bool shouldRun = mySystem.ShouldRunSystem () ;

• Then making sure, no other job is executed, before critical job is running, I use enumerator

enum SysAlter
{
  Ready,
  Request,
  Set,
}

// First prioritize first system readySystem update.
if ( readySystem.ShouldRunSystem () && sysAlter == SysAlter.Ready )
{
  readySystem.Update () ;
  sysAlter = SysAlter.Request ; // Next system
}
...
// Next requestSystem update is executed, when my readySystem is complete.
// This is defined, by setting entity tag, and read by requestSystem GetEntityQuery group,
// enabling system to run.
if ( requestSystem.ShouldRunSystem () && sysAlter == SysAlter.Request )
{
  requestSystem.Update () ;
  sysAlter = SysAlter.Set ; // Next system
}
...
// Then same for last system setSystem, as for requestSystem.
// Only difference is, the enumerator is set back to first system.
if ( setSystem.ShouldRunSystem () && sysAlter == SysAlter.Set  )
{
  setSystem.Update () ;
  sysAlter = SysAlter.Ready; // Back to first system
}

I understand this is not the best solution and I may realize, it does not work for A or B case, but this approach work so far for me, allowing me accelerate simulation, ensuring jobs not going out of sync.
When simulation is in fast forward, is not matter for me, if simulation isn’t smooth, as long is deterministic.

I need highlight also, I haven’t finished this implementation, but so far, it appears to me, it removed other issues with jobs duplicating data, which I was fighting just past week.

Thx @tertle for your inputs.

[tertle]

Feel like I just answered something very close to this here

Having a job that makes structural changes run across multiple frames

You have to manage the job handle yourself and don’t pass it back to the job system and it won’t complete. This means your ECB will have to be handled by you as well (not from a barrier). That said it’s unwise to use a ECB in a multi frame job anyway as there is usually no guarantee that the Entity exists, has the same components etc. Generally if you need to do a multi frame job you would. Copy required data from entities into containers. Work on data over as many frames as you want. Copy d…

Tldr:
Duplicate your data
Manage the handle yourself, don’t return it
Can’t use ecb from barrier, have to handle it yourself
You probably shouldn’t be doing this

[Antypodish]

Ah, yes I have seen this thread, but haven’t read initially. Now I did.
Your responses confirms my concerns and my observations.
As you primarily suggested in the link, one way is to reduce number of entities in ECB.
But that wont guarantee stability (none duplications of data), since I try to fast forward simulation.
Managing of the job handle is my current direction, I look at indeed.
Than you for pointing out.

On side note, I think you have posted in the past (can not find it ), regarding putting job handle in array, or list? Not sure however, if was that about actual job handle, or was rather manual system update, which we discussed recently anyway. Or maybe it was something completely in different context. Can you recall anything relevant?
I am starting loose my mind?