Jump to content
  • Advertisement
Sign in to follow this  
wodinoneeye

Dual Core Programming - multithreading requirements??

This topic is 4846 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

My previous programs were done on Microsoft C++ using multi-threading (seperate threads for main game loop, rendering, fileIO, Network, Music ...) and I have been using Critical Sections to prevent data access problems between the threads. From what I understand, 'threads' are more lightweight than 'processes' and I now wonder whether Critical Sections and threads are operable across the two CPUs (2 caches...) in a dual core system. Will Microsoft's threads automaticly jump across to the other CPU or are 'processes' now required to make use of the available CPU resources by one program ?? Context switching of processes takes alot more cycles as do semaphore/flag operations to protect common data. Since dual core CPUs are becoming common, this subject is no doubt of interest to many game programmers. [Edited by - wodinoneeye on August 9, 2005 4:42:31 AM]

Share this post


Link to post
Share on other sites
Advertisement
Yes, a multithreaded program will make use of multiple cores, with more than one thread possibly executing at any one given time. If you've done multithreaded programming however, I'm sure you can imagine the difficulties involved in sharing data between them. For game programming, the technical issues of correctly using mutexes (or critical sections, or any one of a dozen other names) isn't even the biggest problem. A multithreaded app is much more demanding in terms of the overall design of the engine. It must be very modular and self-contained in order to really be able to benefit from multithreading, otherwise the overhead of obtaining and releasing locks will outweigh the benefits in many areas.

The biggest problem is the scene graph. Scene graphs are not trivial containers, and they're generally involved in a lot of operations. It's also not exactly simple for most implementations to lock data in one portion of the graph without locking the entire thing, which forces any other thread that wants to use it to wait. In a graph strucutre, you also might have recursive locks going down a tree colliding with recursive locks going up, ie, a deadlock nightmare.

It is no trivial thing to implement multithreading for game engines, which generally involve a lot of data, and a lot of object to object interactions. It will require new approaches to a lot of issues. It is possible, but it will be a lot more difficult to make a good multithreaded engine than a game engine as we know it today.

Share this post


Link to post
Share on other sites
Quote:
Original post by Nemesis2k2
Yes, a multithreaded program will make use of multiple cores, with more than one thread possibly executing at any one given time. If you've done multithreaded programming however, I'm sure you can imagine the difficulties involved in sharing data between them. For game programming, the technical issues of correctly using mutexes (or critical sections, or any one of a dozen other names) isn't even the biggest problem. A multithreaded app is much more demanding in terms of the overall design of the engine. It must be very modular and self-contained in order to really be able to benefit from multithreading, otherwise the overhead of obtaining and releasing locks will outweigh the benefits in many areas.

The biggest problem is the scene graph. Scene graphs are not trivial containers, and they're generally involved in a lot of operations. It's also not exactly simple for most implementations to lock data in one portion of the graph without locking the entire thing, which forces any other thread that wants to use it to wait. In a graph strucutre, you also might have recursive locks going down a tree colliding with recursive locks going up, ie, a deadlock nightmare.

It is no trivial thing to implement multithreading for game engines, which generally involve a lot of data, and a lot of object to object interactions. It will require new approaches to a lot of issues. It is possible, but it will be a lot more difficult to make a good multithreaded engine than a game engine as we know it today.



Yes, I was already rigidly restricting the common data accesses (mostly buffer handoffs between network and gameloop or fileIO and gameloop (rendering is on the client with a minimal game loop and the server (big game loop) has no rendering). Each sub-process was designed to be mostly self contained -- the server event mechanism having its own state scheduler, etc... with calls to the other thread's shared data being as brief as possible -- buffers being traded
via critical section protected flags (mailbox type protocols). I wasnt even thinking of mutli threads for the rendering... (Im using 'chunk' type world map
so the rendering data set granularity is large).


The critical sections (intra thread) have low overhead, but I am concerned that if they get expanded (a inter process level equivalent is substituted) there will be much greater overhead - even with my narrowed common data accesses.
{MSDN talks of critical sections as only 'existing between threads within a process ' and I dont think that you can have parts of a process running on 2 different CPUs simultaneously, thus will take a more heavyweight interlock.}
Since the mutex would now have to cross into different CPUs caches (and I havent heard how well Intel or AMD have made their dual core Locks) I would expect a slowdown.

There may be a tradeoff of gaining fewer thread switches (half??) if the threads dont have to switch as frequently, some being resident on the second CPU (assuming you can designate which CPU a thread lives on).
Another gain could be the use of SpinWaits (only works if more than one CPU for very short duration critical sections) again only if you can designate exactly which CPU each thread runs on.


Supposedly the big plan is to back off from high Ghz CPUs, use somewhat slower
dual cores and shift to larger caches (and for Intel - change the architecture to something like the Pentium M). We will be stuck with splitting previous single CPU processes (90+% monolithic usage) into 2 or more slower CPUs (never to go above 4ghz, probably staying in the 3ghz range).

Hopefully the hardware will have features to minimize mutex operations overhead.








Share this post


Link to post
Share on other sites
Sign in to follow this  

  • Advertisement
×

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

We are the game development community.

Whether you are an indie, hobbyist, AAA developer, or just trying to learn, GameDev.net is the place for you to learn, share, and connect with the games industry. Learn more About Us or sign up!

Sign me up!