Concurrency and Multithreading in Game Design

For now we can use this place to post links to articles about concurrency in game design. Hopefully in the future some of those articles will actually be from this wiki.

Concurrent programming in game design, is going to become more and more relevant in the near future considering CPU makers are increasing the number of cores on their CPU’s (currently 2 but soon 4, 8, 32 who knows!!), so programmers need to start thinking multithreaded if they want to be able to harness the power of the next-gen systems (3 cores for the XBOX 360 and 7 cores for the PS3 , and the graphics card GPU’s already contain many parallel pixel and vertex processing pipelines).

To harness the multiple CPU cores new architecture has to be developed, which basically means that game engines need to evaluate what in the game simulation can be scalably parallelized (scalability is essential because it’s easy to break game simulation into 2 or 3 synchronized tasks but if it doesn’t scale to 32 processors then it’s very limited).

• Testing Concurrent Programs
• The Free Lunch Is Over: A Fundamental Turn Toward Concurrency in Software By Herb Sutter
• Multicore Programming Primer: Learn and Compete in Programming the PLAYSTATION®3 Cell Processor - Interesting lectures from an MIT course in multicore programming.
• Javolution's ConcurrentContext - The Javolution high performance real-time library provides a ConcurrentContext which allows a programmer to develop parallel algorithms that fully utilize a multicore, multiprocessor system (with speedup benchmarks of up to 1.85x on a dual-core system, for highly parallelized algorithms).
• The Next Mainstream Programming Language: A Game Developer’s Perspective - Tim Sweeney's powerpoint showing the different layers of parallelism
• Multithreaded Game Engine Architecture
• Source Multicore
• Threading 3D Engine Basics
• Amdahl's Law
• Managing Concurrency
• Coding For Multiple Cores on Xbox 360 and Microsoft Windows
• Software Transactional Memory - The idea is very similiar to atomic transactions in the database world, STM optimistically assumes that any concurrent transaction that is made on shared memory is going to be done without another thread trying to access that shared memory. The key idea is that it makes the concurrent code developer not have to write explicit synchronization to perform actions, but once that threads transaction is submitted then the application will validate that no other thread has accessed that shared memory, and then commit it. If it fails then the transaction is retried, in real practice this transaction retry mechanism has proven more efficient because actual conflicts are rare, rather than having threads explicitly acquire locks per transaction. In the end STM provides a way of creating a highly concurrent application (it will scale to N processors/cores).
• Multithreading Game Engines For Multicore Machines
• Multithreaded Game Scripting with Stackless Python
• jME Multithreaded Madness - A post on Mark Powell's Blog, describing his perspective on the future concurrent architecture of the Java Monkey Engine.
• Multithreaded Concurrent Game Design and Architectures - A post on doug daniels developer blog summarizing some initial research I did on game design and concurrency (pretty much repeating everything I'm saying here)
• Simulated Concurrent Game Scripting using coroutines - A post on doug daniels developer blog describing a scripting architecture that lets game designers design scripts in a more intuitive manner.
• Multithreaded concurrent Game Design and Architectures - Java monkey engine forum post.