Refactoring for Task Concurrency

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?

You can read the full article over at AltDevBlogADay.com.

 

 

Advertisement