I'm the process of designing/developing my game engine. I have a plan to make it scalable for (n) CPU's. This is my first engine and some of you might think it's a joke to go for multi-threading considering that, but I like a challenge and would much rather aim high than low. Plus by the time it's finished it will have to support multiple CPU's to be worth a bean. Anyway the design is this: CORE: Handles thread management and based on how many CPUs a system has it makes a sub core each dedicated to it's own thread. Also keeps track of total number of each different element game wide. Controls program functionality. Depending on how many *edit*elements*edit* there are, it divides a jobs workload between the sub cores if the job is of considerable size. || || SUB CORE(S): Holds instances of all manager objects. || || MANAGER(S): Keeps track of element creation/updates/destruction/instance amount of elements. || || ELEMENT(S): Controls element specific loading/behavior/rendering. Note that this design is still sort of a work in progress and may not include everything needed, which is why I'm posting it here for criticism and comments. Chances are I'm missing some things but keep in mind this is my first attempt at designing/creating an engine. Please let me know of any specific problems I might encounter with this design or your opinion of the design. [Edited by - etsuja on May 24, 2007 7:19:25 PM]

One thing that I was thinking about was that if you have more than one thread running each on a different CPU and they were both declaring variables would there be a chance of a memory conflict and how big would the chance be? These two threads don't share any variables at all.

Each sub core will do it's own processing of everything required for each element. The only communication I will need is when elements from one thread interacts with another. I could try to ensure that elements that need to interact stay on one thread for the most part but that won't always be possible. What I'm thinking of doing is having any information that needs to be transfered to another thread/element is first making sure no other threads are accessing the core variable data then sending the new info up to the core then passing it down to the other element which would make some parts of my code non supporting of multiple cpus but I would only need to do this on occasion where one element from one thread interacts with an element on another thread.

I don't plan on having every job multi threaded but most jobs will be. I'll have to make my jobs called by the sub core of an optimal size so that when I do need to poll threads or possibly put a halt on one it won't take too long.

There's probly some things I'm missing but as for now I'm dividing and somewhat conquering.

*EDIT* One thing that I forgot to mention is that this is going to be an exclusive DirectX 10 engine (at least initially) so I'll have to share the devices and keep an eye on them.

[Edited by - etsuja on May 24, 2007 7:11:16 PM]

I know what I posted isn't real in depth but does anyone else have any more feedback at all?

Without any more information, the main issues you will have is dealing with any multithreaded system is shared data locking, thread locking and synchronization.

You need to detail how you are going to solve these issues.

Quote:Original post by yaustar
Without any more information, the main issues you will have is dealing with any multithreaded system is shared data locking, thread locking and synchronization.

You need to detail how you are going to solve these issues.

Thanks for the feedback, I don't have solutions to those things figured out at the moment, although with this design I don't believe I'll have an incredible amount of data sharing between threads. Mainly the way I have it planned, I'll just have to manage the data between the main/core thread and the other sub core threads. I havn't looked into it too deeply but I'm thinking of using openMP for thread management. I probly won't post solutions to those problems when I come up with them just since this thread wasn't meant to be a real in depth detailing of my engine just the basic outlying structure but thanks for pointing them out.

Say you had three 'managers', physics, rendering and update of behaviours. They will all share the same core data such as position, how will you manage that between threads? How would you make sure that any changes will be atomic? If you don't want to multi thread them, how do you make sure that all the managers are all on the same thread? What happens when the behaviour of an entity wants to affect the physics of an object (Eg apply a force)?

Position won't need to be shared between elements on different sub core/threads unless elements from one thread needs to interact with one from another (which will be checked in the core) in which case I'll gather the data each thread needs from the other and send it to the core then send the required data from the core to the threads. Same thing for the physics. With the required data each thread will take care of it's own physics. Thanks for bringing these things up. K, so now I know I need to keep communication in check. Anything else that isn't communication\thread management related?

Quote:Original post by Ravuya

Quote:Original post by etsuja
One thing that I was thinking about was that if you have more than one thread running each on a different CPU and they were both declaring variables would there be a chance of a memory conflict and how big would the chance be? These two threads don't share any variables at all.

Unless they're sharing variables, your chance of problems is pretty low (I think stack allocation and new is atomic).

Well stack allocation should be comming from a different stack for each thread so that shouldn't be a problem. [grin]