On Mon, 24 Oct 2005 11:08:06 -0700, Andy wrote in message
[EMAIL PROTECTED]:
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.
..and clusters. ;o)
+ 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.
..can we get both multi screen wrap around cockpit style immersion movie
theaters and formation flight?
+ 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.
--
..med vennlig hilsen = with Kind Regards from Arnt... ;o)
...with a number of polar bear hunters in his ancestry...
Scenarios always come in sets of three:
best case, worst case, and just in case.
___
Flightgear-devel mailing list
Flightgear-devel@flightgear.org
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
2f585eeea02e2c79d7b1d8c4963bae2d
