Hey, I'm working on a game engine that I'm going to use on all of my future games. Right now I have an actor based system where the game logic can add and remove actors and a process system (all of this is based on the game coding complete architecture recommendations). The event system is what I described in my other thread (it has a map of vectors of event listeners. The key in the map is the event type). I want to multithread this for maximum performance and I ran into some design issues. Should I have the update function for the actors start a seperate thread and update the actor array as normal, while doing the other game logic updates in the main thread? And what kind of synchronization will I have to do for my event system? Will I need to manage access to the event manager's array using critical sections when sending events, receiving events, or both?
Thanks for any help.
Threading an event and actor system
Why do you want to multithread? Do you have experience performing multithreaded operations?
Author
No, I haven't had experience performing multi threaded operations. And the reason I want to thread is for maximum performance. I'm not going to actually thread it yet, but I want my architecture to be "thread friendly". I want to build the architecture from the start as something that's easy to thread.
While threading is an architectural consideration it's not really part of the architecture itself because it's highly context specific. You can't multi-thread loading a sorted list in a list box, for example. Well, you "can" but that would just be weird.
The biggest thing to keep in mind is synchronization. You can put things in other threads all day long but if you don't keep things in order your code will behave in uncontrollable ways and will be riddled with bugs. Unless an operation is entirely dependency free, you will need some method of synchronizing and locking data so everything comes out as it needs to be. In the example of writing to a list box, you can use as many threads as you want but when each thread goes to access and add an item to the list box you'll need to lock the list box object so only one thread can interact with it at any given point in time because memory can't be written to simultaneously from multiple sources.
What technology are you using? C++, C#,....?
The biggest thing to keep in mind is synchronization. You can put things in other threads all day long but if you don't keep things in order your code will behave in uncontrollable ways and will be riddled with bugs. Unless an operation is entirely dependency free, you will need some method of synchronizing and locking data so everything comes out as it needs to be. In the example of writing to a list box, you can use as many threads as you want but when each thread goes to access and add an item to the list box you'll need to lock the list box object so only one thread can interact with it at any given point in time because memory can't be written to simultaneously from multiple sources.
What technology are you using? C++, C#,....?
Author
While threading is an architectural consideration it's not really part of the architecture itself because it's highly context specific. You can't multi-thread loading a sorted list in a list box, for example. Well, you "can" but that would just be weird.
The biggest thing to keep in mind is synchronization. You can put things in other threads all day long but if you don't keep things in order your code will behave in uncontrollable ways and will be riddled with bugs. Unless an operation is entirely dependency free, you will need some method of synchronizing and locking data so everything comes out as it needs to be. In the example of writing to a list box, you can use as many threads as you want but when each thread goes to access and add an item to the list box you'll need to lock the list box object so only one thread can interact with it at any given point in time because memory can't be written to simultaneously from multiple sources.
What technology are you using? C++, C#,....?
I'm using C++, and I'm going to write a wrapper around win32 threads so that I can easily port my threading system to other platforms.
I'm using C++, and I'm going to write a wrapper around win32 threads so that I can easily port my threading system to other platforms.
Dude no need too, this has already been accomplished.
My professor always says there's no reason to reinvent the wheel.
Boost::threads
They also already have the code for pausing and waiting on other threads so no shared data is read at the same time.
boot::mutexs
The best part is the Boost library is that it is not platform specific.
Boost Library
Author
[quote name='3DModelerMan' timestamp='1305918864' post='4813579']
I'm using C++, and I'm going to write a wrapper around win32 threads so that I can easily port my threading system to other platforms.
Dude no need too, this has already been accomplished.
My professor always says there's no reason to reinvent the wheel.
Boost::threads
They also already have the code for pausing and waiting on other threads so no shared data is read at the same time.
boot::mutexs
The best part is the Boost library is that it is not platform specific.
Boost Library
[/quote]
I think I will. I didn't realize that Boost was open source, now that I know that I'll be sure to use it.
[quote name='3DModelerMan' timestamp='1305918864' post='4813579']
I'm using C++, and I'm going to write a wrapper around win32 threads so that I can easily port my threading system to other platforms.
Dude no need too, this has already been accomplished.
My professor always says there's no reason to reinvent the wheel.
[/quote]
What? Yes there is. Assuming that the technology out there is better than anything you could write, due to the man hours spent on it by experts is completely fine.
Unless your goal is to learn. If your goal is functionality, then yeah, you might as well go for the boost libraries, but if you want to learn more about threading, then write your own. There's no reason as to why you couldn't move from your own back to boost after it's complete. But if you want to learn as much as you can, writing your own, at least for the initial stage, may be better than going directly for third party libs.
"Unless your goal is to learn."
But you're also talking about writing a game engine AND a game.
You should pick one thing to learn, and you should pick it carefully. You will finish at most one of the things you will choose to learn -- usually the one closest to the thing you decide to learn.
If you decide to spend your time playing with a threading system, your threading library is what you're most likely to ship -- you'll never get to the rest of your "engine" or the games.
Most IT projects, big or small, which fail fail because they decided to try and do more than one thing. They decide to not only solve a business problem but ALSO to learn a dev system or use a new design process or port something to new hardware.
If you want to ship a threading library, faff about with threading fundamentals. If you want to ship games engines, write games engines.
If you want to ship games, write games.
But you're also talking about writing a game engine AND a game.
You should pick one thing to learn, and you should pick it carefully. You will finish at most one of the things you will choose to learn -- usually the one closest to the thing you decide to learn.
If you decide to spend your time playing with a threading system, your threading library is what you're most likely to ship -- you'll never get to the rest of your "engine" or the games.
Most IT projects, big or small, which fail fail because they decided to try and do more than one thing. They decide to not only solve a business problem but ALSO to learn a dev system or use a new design process or port something to new hardware.
If you want to ship a threading library, faff about with threading fundamentals. If you want to ship games engines, write games engines.
If you want to ship games, write games.
Unless your goal is to learn. If your goal is functionality, then yeah, you might as well go for the boost libraries, but if you want to learn more about threading, then write your own. There's no reason as to why you couldn't move from your own back to boost after it's complete. But if you want to learn as much as you can, writing your own, at least for the initial stage, may be better than going directly for third party libs.
You don't learn anything this way.
Abstracting away individual threading APIs doesn't teach anything. It's a mundane tedious work on a completely solved problem. Especially considering boost::thread is what will now become std::thread, a part of standard library.
Writing wrappers not only does not teach anything about multithreading, it will leave you oblivious to a million tiny details that are involved in such work and which has taken hundreds of seasoned veterans to slowly work out all the kinks.
Even more - someone who wants to do anything useful and learn anything meaningful, the following APIs are a must to learn:
- POSIX pthreads (the linux/unix way)
- WinAPI threads (Windows alternative)
- OpenMP (not ideal, but closest to standard)
For C++, boost's threads are the C++ wrapper over POSIX-like functionality, taking into account certain restrictions of both the target platforms as well hardware and language limitations.
Individual industries may use others as well, either specific libraries or variations on the theme above: TBB is one example of such specific library.
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement
