Curtis L. Olson wrote: > I would like to make a case for non-threading from the standpoint of > simplicity. We have had (and probably still have) some extremely > subtle and extremely difficult to track bugs in our threaded tile > loader.
I don't disagree at all. Everything you say is true, and a reason to avoid threading wherever possible. Naive thread architectures are invariably a disaster. But unfortunately the hardware world conspires against us -- SMP is rapidly becoming the rule rather than the exception for high performance desktops. Note that there are a few spots where we could split out separate threads in a relatively clean manner: + FDM: Put a lock around the input and output stages (or wrap them into an object that can be placed in a synchronized queue) and let the actual numerics work happen on a different CPU. The advantage here is that you can crank up the simulation rate quite a bit on SMP/multicore boxes, leading to (at least with YASim) more stable ground handling. + Audio: drive the "OpenAL" thread with a simple command stream from the main loop. One many systems, this will (might, if OpenAL doesn't already do this) move the mixing off of the main CPU, which is good. Even better, it will decouple the audio stream from the main loop latency issues and make "skips" easier to handle. + Rendering: One idea here would be to "clone" a separate scene graph (just the non-leaf animation nodes, really) and let one thread (the renderer) draw it while another (the main loop) gets the next one ready for rendering. When done, you do a synchronized "graph swap", or even triple-buffer it for higher throughput at the expense of latency. This would require significant surgery to the existing model/animation code (and, to a lesser extent, the GUI and tile code) to store the property values somewhere instead of reading them at render-time. + Everything else: This thread would contain the existing main loop, and its basic structure wouldn't change. Note that this design allows threads live by relatively simple rules. The main loop doesn't change much except where direct calls are replaced by commands to be queued. And the worker threads all work only on their internal data; they don't need (and are forbidden) to touch external state like the property tree. The first two could be done with fairly minimal code, actually. The renderer changes would be more significant. Andy _______________________________________________ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
