This project is read-only.

concurrency/multi-threading

Jul 26, 2010 at 6:09 PM
Edited Jul 26, 2010 at 6:11 PM
Are there any plans in progress for adding concurrency support for Box2D.XNA? Previously there was brief talk about adding some concurrency in the island solver (with each island getting its own thread), but with the release of .Net 4.0 (or the parallel extension library for .net 3.5), it may be possible to get more fine-grained/load balanced concurrency through the use of the parallel extension library which is now part of the base .net 4.0 library:

http://download.microsoft.com/download/3/4/D/34D13993-2132-4E04-AE48-53D3150057BD/Patterns_of_Parallel_Programming_CSharp.pdf

So, for example, even if you had only one island (pyramid example), you could still split out the work into multiple threads. Also, a big benefit of going this route is that, if we stick to simpler Parallel.For/Parallel.ForEach and similar constructs, it may be possible to support this concurrency in the .net version while staying relatively close to the original box2d C++ library.

However, one major problem I see is that in many places where the code would benefit from concurrency, there is mutable shared state that would make it impossible without further refactoring. For example, it would be possible to convert the for loop in CollidePolygons to a Parallel.For, however I think it would be more efficient to parallelize one step higher, but it looks like some shared state is being modified between calls to CollidePolygons which would have to be synchronized or preferably eliminated.

Any thoughts?
Jul 27, 2010 at 7:51 AM

We definitely have plans to make island solving multi-threaded, but first we need to set up some good benchmarks to know if we are helping/hurting and to tweak any heuristics we put in place.

Using .NET 4 constructs would be ideal, but we need Box2D.XNA to run on Xbox360 which does not support .NET 4.0 to my knowledge.  We will probably roll our own parallel solution since it will likely be a simple branch/barrier mechanism (ultimately the physics will act like a single-threaded component of the game, but can branch into parallel work when appropriate and then wait for the threads to finish and signal the UI thread to continue).

Jul 27, 2010 at 9:30 PM
It is starting to sound like that might be the best option for now. It doesn't look like the task parallel library is supported in xna 4.0 for xbox 360 or windows phone 7, and while the Rx extensions library is supported for windows phone 7, it currently is not supported for xbox 360 projects. I got a reply from Jeffrey van Gogh on MSDN: http://social.msdn.microsoft.com/Forums/en-US/rx/thread/fd344f71-2cf6-4dbe-8bc0-977762923ba8

It appears the issue with the TPL is that it uses unsafe code and P/Invokes which make it impossible to deploy as a standalone library, so the only way we'd be able to use it is if it were a pre-installed system library. Unfortunately, it doesn't appear it was included in the XNA 4.0 distribution, so I'm unsure of the time-frame for that.

The Rx extensions library does currently run on the Windows Phone 7 runtime, however, and Mr. Gogh said he is looking into possibly getting it ported to xna 3.1 and hopefully xbox360, so that might be a route we can take. You can sort of emulate the TPL with Rx, though I'm not sure it would be as optimal as using either TPL directly or Rx the way it was designed to be used (via linq), but given that xbox360 can use more than one core for threading, we might still get a net gain.

So, I would recommend going ahead with your original plan, but implement your custom parallel solution to have the same interface as the TPL (there is a naive implementation of Parallel.For and Parallel.ForEach in the paper I linked to earlier, which you could possibly use as a base to tune up). That way Windows XNA clients can use the TPL directly, xbox 360 could use the custom implementation, and you can experiment with different implementations (like an Rx back-end, for example) without changing the client code.