Anyone using multiple threads in their C gauge?Just wondering.

Yes, I do ;-)What do you want to know about threads?Eric

Eric,Nothing in particular right now, I just was wondering if others were using them successfully with FS.Did you run into problems?

Hi guys,I've not been into threads yet. I kinda have an idea what they are, but I have little idea how to use em. More interesting in the first place tho to me is under which circumstances you use or have to use multiple threads.Thanks for any insight. :-hahCheers, :-beerchugEtienne :-wave

I am new to them too.They are good for when you want to go do something asyncronously, meaning you don't want to wait for that process to finish to continue, as it might take "awhile" (longer than you want to pause).So, if you are going to ask the computer to scan a file from DVD, for example, you might want to continue processing in your main thread, while another thread finishes that task and reports back to you.

Or, one might want to have all calculations and bitmap rendering running in its own thread outside of the sim's "loop," and have it send back only complete bitmaps, ready for display... ???

Nice idea. :)

I'm assuming FS is multi-threaded, and that if we use COM objects that we must use "critical-sections" to avoid problems.I am finding that everything I'm doing works, but that after a few seconds, FS processor usage goes to 98%, (from 40%), while memory usage remains stable (suggesting no memory leak). To me, this suggests that I may have some threads deadlocked.Is this what you might expect from this happening?I have another theory I'm going to test out today too, that this results from a message pump filling up and not being handled.

>Or, one might want to have all calculations and bitmap>rendering running in its own thread outside of the sim's>"loop," and have it send back only complete bitmaps, ready for>display... ???Just what I thought about some day. I did not get into threads yet, neither did I get predrawn bitmaps to draw. Probably I am missing something stupid. What I wanted to do is draw parts of a gauge which don't ever change or don't change every update cycle to a bitmap once, then use these 'precalculated', ready-to-use bitmaps. Huhm I've gotta try that again once I find the time.

My experience of using threads in XP on a single processor is limited but it suggests that for multithreading to work effectively it's necessary to use:- critical sections to share data safely between threads- semaphores to share resources safely between threads- event objects to make a thread wait for an event to occur.These are in addition to starting and terminating the individual threads.

This is absolutely right.Another interesting work for a thread can be to fetch the navigation database while the aircraft is flying. FS doesn't need to wait for the database access to keep flying...In addition, multi-threading is very interesting here because FS itself runs in a single thread, which leaves CPU power unused if you have a dual core processor.Eric

I agree but it's important to remember that there's no such thing as a free lunch.If there is a given amount of processing to be done on a single-core processor then the overheads of managing multiple threads can reduce performance - it's inceasing the processing load. There can be advantages if one thread can be put into the background allowing the other to have a higher priority and complete faster. Of course, you can achieve the same effect without threads as shown (hopefully) in the following simplified code snippet:Interval = 10;while (...){++Counter;{// Start of high priority code..// End of high priority code}if (Counter % Interval == 0){// Start of low priority code..// End of low priority code}}The low priority code will be executed once for every Interval executions of the high priority code.Incidentally even with a dual-core processor there is no guarentee the using threads will improve performance. Look at Figure 9 of the following link. This shows that, unless there each thread does a significant amount of processing then the performance can be reduced by up to 95% because of the overhead in managing the threads. At the other extreme it shows that achieveable performance improvement is limited to 65% because of the overhead. Admittedly this relates to a particular situation but the general principles will apply universally. This could also explain the incease in processor usage that Patrick Waugh reports, which could be due to the thread overhead.http://msdn.microsoft.com/msdnmag/issues/0...MP/default.aspx

Interesting link MGH...as you say, "there ain't no free lunch";-)