Shouldn't there be three? Or is FlightGear not getting inputs from the user
when it hangs?
Well by my count: 1. main thread, 2. scenery paging thread, 3. weather fetching thread.
My opinions on:
Subtle bugs -- these get hidden anyway without the "help" of multiple threads.
Seriously, and believe me when I say this. Threads open the door to a whole new level of even more subtle, difficult, and hard to trace bugs than you would have otherwise. I suspect you won't buy that, but it's true. Threading bugs are nasty because subtle timing issues can produce code that works fine for hours or perhaps only bomb once every couple days. This can be incredibly difficult to debug because it is nearly impossible to reproduce and the debug/edit/compile/run cycle can be hours or days for one iteration. The tendency is often that if it works most of the time, and it's hard to find the problem, let's not worry about it and move on. Pretty soon you have an application that has trouble running more than an hour or two without crashing due to a number of different bugs that have crept in. And if you get to that point, you need the resources of, oh, let's say microsoft, to dig yourself out of that hole. Not that I would pick on microsoft in this context for any particular reason.
Seriously, threads are really cool in a simple text book example, but in a complex real world application, danger, danger, danger!
Consider one end, you have a code that takes up 0.5% of the processor time
updating the property tree, and on the other hand, you have an external
application that is feeding off these properties to drive a hydraulic motion
platform. [snip]
#1 is completely out of the question, as someone could be killed. So, #2 is
the only viable option. Unfortunately, single thread and #2 don't mix,
because alarms would be going up all the time.
Clearly there are cases where you can't proceed with out threads. Threaded scenery paging is one, threaded metar fetching is another. Neither consume a huge amount of CPU time over the course of the application, but each has specific reasons why it makes sense to put those in a thread.
But threading even these "simple" things has been extremely painful. I've been intimately involved in that pain several times for each of these threads.
Really! We should go out of our way to find a workable non-threaded solution before we add new threads to the code.
But if we just want to make use of our fancy multi-core CPU's, well then, hold on a second, what chunk of cpu intensive stuff are we planning to move over and run on another thread on another core?
My whole point is not that we should never do threads because we already do in a couple special cases. But we just need to be really smart, really thoughtful, and really actually require a thread before we put ourself through the pain and a new order of magnitude of subtle bugs again.
Curt.
--
Curtis Olson - University of Minnesota - FlightGear Project
http://baron.flightgear.org/~curt/ http://www.humanfirst.umn.edu/ http://www.flightgear.org
Unique text: 2f585eeea02e2c79d7b1d8c4963bae2d
------------------------------------------------------------------------- Using Tomcat but need to do more? Need to support web services, security? Get stuff done quickly with pre-integrated technology to make your job easier Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642
_______________________________________________ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
