Multithreading Madness?

This is a discussion on Multithreading Madness? within the Game Programming forums, part of the General Programming Boards category; I've been toying with the idea of multithreading in my games logic and I've come to an impass. I'm far ...

  1. #1
    Professional Chef leeor_net's Avatar
    Join Date
    Apr 2004
    Location
    Charles Town, WV
    Posts
    147

    Multithreading Madness?

    I've been toying with the idea of multithreading in my games logic and I've come to an impass. I'm far from an expert on multithreaded programming (in fact, I'm a total novice) and I know that multithreading will not speed up my program only allow it to be more responsive but I've been wondering exactly what would be considered overkill?

    I was thinking of having all of my in-game objects (entities) doing their logic in their own threads. However, there's the possibility for thousands of entities so would it make sense to create a new thread for every Entity? This seems like overkill and I can see it even slowing down the program and even possibly causing problems with the operating system.

    So I suppose the question now is how can I do multithreading with my entities such that the program remains responsive (e.g., continuing to render frames even if the logic for all entities hasn't been completed). Would it make sense to through an update loop into a thread that simply iterates through a list of Entities telling them to perform their logic?
    - Leeor

  2. #2
    Guest Sebastiani's Avatar
    Join Date
    Aug 2001
    Location
    Waterloo, Texas
    Posts
    5,708
    Well, the first thing to remember is that the two words "multithreading" and "madness" are quite often synonymous. Keeping that firmly in mind, you should ask yourself if there is some way to avoid it, if possible, using some other technique. You could, for example, have an update_entity function that is called in a loop to keep each entity going in a synchronous-like fashion. Of course, coming up with a system that works in that way has it's own unique challenges and limitations, so you may end up being forced to use threads, after all. In that case, having a good book on concurrency handy is always a good idea.

  3. #3
    and the hat of wrongness Salem's Avatar
    Join Date
    Aug 2001
    Location
    The edge of the known universe
    Posts
    32,548
    If you've got lots of dependent data (your objects are moved by one thread, and rendered by another), then threads are going to be a disaster waiting to happen.

    By the time you've thrown in all the mutexes and semaphores to guarantee correct concurrent operation, the performance of the whole thing will suck.

    A "render thread" and an "everything else" thread might make sense, particularly with multi-core machines becoming fairly common. But you still need your head screwed on to make a decent job of it.


    If you thought debugging is hard now, just wait until you try to debug your first race condition.
    Unusual software bug - Wikipedia, the free encyclopedia
    If you dance barefoot on the broken glass of undefined behaviour, you've got to expect the occasional cut.
    If at first you don't succeed, try writing your phone number on the exam paper.
    I support http://www.ukip.org/ as the first necessary step to a free Europe.

  4. #4
    Professional Chef leeor_net's Avatar
    Join Date
    Apr 2004
    Location
    Charles Town, WV
    Posts
    147
    Heh. Yeah, I've avoided multithreading as best as I could up until this point (needed to do it for my updater utility to have the download function working in a thread while the rest of the program continued to operate... it's still not completely totally 100% perfect but it does the job (had issues with race conditions then that I've since corrected.... *shudder*).

    Anyway, the idea for me was to have the logic calculations of the entities running in their own thread to keep that stuff in the background while the rest of the program continued merrily along rendering away (graphics are totally separate from the logic itself).

    Basically what I'm getting is that there's point to using multithreading in this case and I should just go with a straight-forward, more 'traditional' approach.
    - Leeor

  5. #5
    Super Moderator VirtualAce's Avatar
    Join Date
    Aug 2001
    Posts
    9,596
    Rendering is a linear process. You cannot present until every object draws and you cannot move to the next update until the previous render finishes. This means even in a thread you will be waiting for every object to draw to the back buffer before you can update the next frame. As such I see no benefit in threading the rendering.

    Good candidates for threads:
    * AI
    * Sound
    * Input
    * Network

Popular pages Recent additions subscribe to a feed

Similar Threads

  1. Multithreading (flag stopping a thread, ring buffer) volatile
    By ShwangShwing in forum C Programming
    Replies: 3
    Last Post: 05-19-2009, 07:27 AM
  2. Question on Multithreading
    By ronan_40060 in forum C Programming
    Replies: 1
    Last Post: 08-23-2006, 07:58 AM
  3. pointer madness
    By moonlord in forum C Programming
    Replies: 11
    Last Post: 08-22-2005, 08:58 AM
  4. Client/Server and Multithreading
    By osal in forum Windows Programming
    Replies: 2
    Last Post: 07-17-2004, 03:53 AM
  5. Multithreading
    By JaWiB in forum Game Programming
    Replies: 7
    Last Post: 08-24-2003, 09:28 PM

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21