This is really more of a follow on from my previous article, Preparing for Parallelism. Some of the comments wanted more explanation, and an example of what I actually mean about the likes of incorrect data and controlling execution context.
What I explained was a tips for a component/entity system, a task based one: concurrent systems, running in parallel, and communicating effectively between each other. Fine-grained parallelism does not apply. I also mentioned the fact that being able to accept, and properly deal with out of date ‘incorrect’ data can lead to some novel opportunities for parallelism.
Not to say the methods I employ lead to perfect parallelism and scalability, I do believe they allow for implementing a level of concurrent operation in a cost-effective manner on current hardware, without the hidden quirks that locks can have creep up on your frame profile. I include ‘lock-free algorithms’ in that, as those can cause nasty contention issues. If you disagree, please comment, as I’m really interested in hearing other opinions and experiences on the matter.
First of all, what changes are those that really make concurrent execution hard, even if you allow for reading data which is possibly a frame out of date?
Data structure modification is the weak point
This understanding is critical: modifying data, in itself, is not a dangerous operation when thinking about concurrent operation. If that write to data changes the layout of data in which you are operating on, that is dangerous. For example, here is the simple operation of adding a new node of data to a linked list, and where the things go wrong: