Developing with Jobs and Native arrays means you sometimes have to write two systems to do one job.
E.g. Your using a grid to store game data and need to scan the grid for patterns/pieces/changes in your game and update their status:
You will need to write:
A scanning system that accesses the grid in read only mode and generates processing data.
An updating system that has write access to the grid to update the states of the cells in the grid.
I understand the reasoning behind the need for cross job access to data but what if there was a way to get one system to do this. If there was a mechanism for flipping the read/write status of the data after the first pass then the second pass could update the data.
A multi-pass system could allow for less system interdependence and reduce the overheads of running multiple systems. It might also help mitigate the code/bandwidth bottleneck inherent in simpler systems that process lots of data but only do minor updates.
Look at it this way the two system approach means you have cycled through loading the data twice, even though you could in a two stage system have fully processed the data in less than two cycles (some data elements may need to be reloaded).
There is another approach where you double buffer or duplicate the data with one set to read only and the other to write but then you are adding a memcpy step as a pre-process.
The particular scenario proposed will only be impacted by combining systems if the data read in the first stage is also being read in other systems and all these stages are IJobs which let them run concurrent to each other. In practice this doesn’t happen very often, so I propose you just start by having both phase jobs run in the same system and only split them if it causes you “bubbles” in your thread utilization.
The issue is the scanning part of the problem, the first system will need to scan the nearest neighbours of each node to process the update status.
For example, a cellular automaton that like life needs to scan it’s neighbours, a chess or draughts game would need to scan for available moves. And the issue is unless you run the scan in one thread you will hit thresholds where multiple threads need to access neighbours on another thread.
PS For most board games with small board sizes this should not be an issue as you could allocate the job size to be equal to the board size.
You can read the same data in parallel. You just can’t write to the same data in the same job. Also, whether something is read or write is dictated per component, not per entity. So you have two jobs. The first job scans and records intent. The second job updates the shared state. Schedule those jobs back to back in a system. Or if you got lots of different algorithms for each phase, then use ComponentSystemGroups, one for each phase.