   Worker Thread Tasks
  As my knowledge of threading continues to evolve and grow, so do my questions on how to properly implement them. So now I am at the point where I am going to design my engine for multiple threads and I want to implement them as worker threads the question comes up: "What is a task."But not in the sence that I dont know what a task literaly is, but more what do I make into a task? I have been pondering about it for a while and can only come up with so many. So here I am asking for some creative help:What things, that are not game specific (ie engine stuff) should I be making into tasks?My idea is that tasks can either be syncable (meaning that they run in parrallel until they are done and then wait for the main program to be ready before ending) or they are autonomous (Something that doesnt need to sync, like playing the current frame's sounds).Im still learning as I go but I really want to get this as close to "right" as possible to minimize refactoring/redesigning later.   
  This really depends entirely on the game you want to make. One game's set of thread tasks is going to be very different from another's.For example, in a real-time strategy game, you might run slow AI calculations on separate threads to avoid blocking the main render thread. The results of the AI decisions can be synchronized back into the rest of the game as needed. However, in a turn-based game, this makes no sense; each AI/player must wait its turn, and therefore doing all of the decision making in a serial fashion is more logical.I would recommend simply designing a framework that exposes your synchronous and asynchronous task concepts. Then when you use the engine to actually write a game, you can assign tasks to the two categories as needed. Locking yourself into too many specifics at the engine level is dangerous and will require a lot of reworking in the future. By contrast, leaving the engine "generic" and requiring the game itself to affect the design decisions will ensure that you don't have to change much code to get things running.I'll leave you with a general guiding principle: never design an engine just for the sake of designing an engine. This inevitably leads to mediocrity. Instead, design an engine to accomplish a particular game. This will ensure that you don't create a lot of useless features, as well as guaranteeing that the engine will do everything needed to actually build the game.   