2 ms·

So a task/job system with explicit dataflow, where data is handed off to the task that uses it, rather than being shared? A lot of game engines do this nowadays

So a task/job system with explicit dataflow, where data is handed off to the task that uses it, rather than being shared? A lot of game engines do this nowadays and it works quite well. It doesn't eliminate synchronisation completely, but it does simplify things a good bit. Ideally, any shared data is immutable (and modifying it would then need to be done in a coordinated synchronised fashion) while most mutable state is only ever owned by one task/thread, with ownership explicitly passed between them as others need access, unique_ptr style. Reality doesn't always match with the ideal though.

Chris_Newton 6y ago
most mutable state is only ever owned by one task/thread For many applications, this is the way I prefer to structure code these days. If you know that the only part of your program that will touch certain state directly is always running in a single thread, a lot of problems just go away, because whatever you do in response to any given message or other signal is effectively an atomic transaction, regardless of any concurrency or asynchronous behaviour you have going on elsewhere in your system. You still need to figure out how your message passing or other signalling infrastructure is going to work and in particular what will block and what won’t, so it doesn’t answer all of the usual questions with concurrency, but it’s a widely useful strategy and it goes a long way toward keeping things manageable.