Is use of Cascade (and depending on results of a lower depth of the cascade) thread safe when using the built-in multi-threading?

[LorenRoosendaal]

Cascade guarantees that operations can be executed starting from for example the root entities of a world and moving up one depth level at a time, which is pretty clear.

I was however curious if, when a system that cascades like this is safe when using the built-in approach to threading:

For example:
-A system that is updating transforms of children based on updates to the transforms of parents counts on the parents all having had their transform updated before the children, as the children then read this transform to then calculate their own.

I couldn't quickly hunt down the entire flow for this, but I was curious if a sync point is automatically added after each depth of a cascading system like this, to ensure ops on depth = 0 have completed in all threads before ops on depth = 1, which rely on the data from depth = 0, are kicked off.

Bonus questions: How about when using instanced, and how about after flattening the hierarchy?

[SanderMertens]

Good question, cascade and multithreading are on my near-term TODO list. The current implementation doesn't work correctly when you make a cascade system multithreaded.

The implementation I'm looking at won't insert a sync point after each depth (that'd be expensive). Instead I'm looking at implementing a light-weight job-stealing task queue in which each matched table will get enqueued as a separate task, with task dependencies enforcing that tables are evaluated breadth-first.

Once that's implemented it'll also work automatically for flattened hierarchies/instanced iteration.