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 
> Regards,
> Curt.


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
Flightgear-devel mailing list

Reply via email to