   "Tasking" Architecture
  Hello all, been a while since I've posted here.  I'm looking for advice on which direction to take with an architecture designed to take advantage of multiple cores.I'm using Intel's Threading Building Blocks, and integrating it into my project.  I have a list of "systems", (graphics, physics, etc), each of which needs some time to execute code (obviously).  Instead of just doing round robin, which is difficult to parrallellize if one has a different frequency than another, and won't take advantage of multiple cores, I'm using a "task scheduling" system.So, each system exposes a "GetNextTask()" function, which will return a task that can be put into the "TaskQueue".  My question is this:Should I use One Task object, which exposes delegates that the Systems can attach too, or should i subclass a base "Task" object for each type of system?I'm not sure I know what the benefits and disadvantages of each would be.  Any input would be appreciated.  Thank you. =)   
  Favor composition over inheritance.Google:Favor composition over inheritance;  The task-based parallel execution model is a useful and widely applicable one. It sounds, though, like you're a little hung up on what exactly a Task should be. At the end of the day, what matters is objects. Each task is an object. Whether you get different kinds of Tasks by making them different classes of a common base class or by parameterizing the same class differently is less important, though limitations in C++ will probably force your hand towards the former option (in a more powerful language, the latter would probably be more convenient). I definitely DON'T think there should be a one-to-one mapping between systems and tasks. Why should Graphics be forced to have only one thing going at a time? I understand what you're trying to get at with uncoupled stepping functions, but I think that that feature is of more limited use, and more limiting in how you can do things, than you expect.   ;  Hah, I don't plan on having a 1 to 1 ratio.  The whole point is that the system itself can configure the granularity.  The get task is to allow the system to determine "What needs doing now", and then when the Scheduler detects that there is some space free in the task queue it retrieves some of these tasks.Also, this is in C#, and with Delegates, the ease of implementing each is trivial.Thanks for the Advice, I think I'm going to go with the Task with an exposed delegate option.   ;  As far as I'm aware, there isn't an Intel TBB version for C#, and that would be a very difficult thing to wrap into a new language.   ;  I'm working on getting it wrapped.  If you'd like, I'll post it online when it's finished.   