Jump to content
  • Advertisement
Sign in to follow this  
wodinoneeye

Impact of multiple CPU -- Critical Sections useable ???

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

With dual cores becoming common and games being forced to use multiple CPUs to get the same (or more) processing power they had before on faster mono-CPUs, do the MUTEXs required to link the 'threads' (gameloop, render, network etc..) of a game program become more heavyweight (more overhead) ???? Does what was done with a low impact Critical Section (on Microsoft OS) now have to be done with Processes (instead of threads) and process level MUTEXs????

Share this post


Link to post
Share on other sites
Advertisement


Spinwaits dont work between 'threads' executing on the same CPU...
So a programmer's control of where different 'threads' execute are important (and hopefully possible???) to enable a spinwait gain. Has anyone seen this control documented anywhere in Microsoft's documentation??

I'm using critical sections to protect flag state changes (for shared buffer access) and linklist node insert/remove (for network packet operations), both used in secondary processes/threads (FileIO, Network) which could be put on CPU2 and the server event processing could be put on CPU1 (and thus spinwaits could be use) -- assuming that kind of control of where processing is carried out exists.

I still dont understand if the two threads running on different CPUs are actually 'Processes' or still 'Threads' as the Operating System sees them.

The 'lock' has to be done across the two CPUs caches now (to test the spinwait's flags). How much longer (cycles) do these locks now take ??? (and is there any significant differences between AMD/Intel ?)

Share this post


Link to post
Share on other sites
Two threads are still "threads", even if they're working on different CPUs. There is more overhead involved, but the overhead of switching processes is still going to be greater than switching threads (though the difference is becoming less with each newer version of Windows).

On a SMP system, critical sections are little more heavy-weight compared to on a non-SMP setup. But they're still lighter than a mutex (which requires a switch into kernel-mode to get a lock).

You can control which CPU a thread runs on by setting it's "affinity" (using SetProcessAffinityMask and SetThreadAffinityMask). But in general this is probably not needed: threads automatically have a "soft" affinity, which means the scheduler will prefer to schedule a thread on the same processor it was last scheduled on. Though it doesn't always do a very good job...

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!