On Tuesday 07 November 2006 10:50, Curtis Olson wrote: > I'm not saying we should not ever do threading in flightgear, indeed we > have two sub threads along with the main program already. Shouldn't there be three? Or is FlightGear not getting inputs from the user when it hangs?
> My only point is we shouldn't thread something that takes 0.5% of the > processor time of the main thread just because we think threads are cool. I disagree. Performance isn't everything. More on this later. > Threads impose a huge penalty in terms of complicating the code, hiding > really subtle bugs, and maintaining threaded code over time just > complicates this matter because new people come in and make changes when > they don't fully understand all the subtle interrelationships (timing, > functionality, etc) of the code. My opinions on: Subtle bugs -- these get hidden anyway without the "help" of multiple threads. New people coming in who don't know what they are doing -- we get these with single thread application too. People just "dive into the code" without any aid of documentation -- the documentation like those used by the mechanic who fixes your car -- the maintenance manuals. And what do people who don't know what they are doing do? They introduce subtle bugs. And other people who don't know what they are doing create the so call "work-arounds" and hide these subtle bugs. And the cycle goes on... So, if the complexity of multithreading causes things to break constantly and whenever someone screws up, it isn't exactly a bad thing. > So sure, we can add more threads, but there needs to be some really > substantial justification for doing it, and if there isn't a significant > performance based justification as part of that, then I will be very > sceptical. Some simulation require the stability of their update frequency. With these, you can't have a process that interrupts and ocassionaly lengthens the length of one iteration. 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. Now, suppose the user is in some maneuver that brings into view a very sophisicated scene, and due to the single thread, causes a momentary lockup of the renderer, and hence the lockup of the simulator. The external application was used to seeing the property tree getting update once per 0.05 second, but now, it sees ONE update of 1 seconds, and assumed that the acceleration as 100g instead of 5g. So: 1) Should the hydraulic jacks try to simulate that 100g? 2) Should the safety system kicks in and shutdown the sim? #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. As you can see, although putting that 0.5% in its own thread would make no performance gain, it would make a huge difference in terms of the realism of the simulation, and its impression on those engineers who are evaluating FlightGear. > > Regards, > > Curt. Ampere ------------------------------------------------------------------------- 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
