I doubt that's the case.  The Task Manager should be displaying all of the  
CPU time used by that process, regardless of where the time is spent.

I think it's more likely that by forcing thread context switches, causing  
your processing thread to have to yield at arbitrary moments, that may  
allow other _processes_ in the OS to get more CPU time than they otherwise  
normally would.  When that happens, obviously the CPU time comes from  
somewhere, which is your processing-intensive process.

You're not specific about how you interact between the two threads.  
However, one obvious solution would be to, anywhere you have a call to  
Control.Invoke(), replace it with a call to Control.BeginInvoke().  Then,  
the GUI thread will only get to process the invoked code when it's really  
its turn, and your processing thread(s) will maximize their use of the CPU.

If you've got other processes on the OS that need to run, they will always  
prevent you from getting to 100% CPU utilization on your own process.  But  
you should be able to get pretty close, and maximizing the use of your  
processing thread's time by not yielding unless absolutely necessary is  
the way to do that.

Note that switching to BeginInvoke() can improve your process's  
utilization of the CPU.  But if you are really posting an update of the  
GUI for every single change to progress, then when the GUI thread does get  
a chance to run, it's going to waste a lot of time performing updates for  
itself that the user will never see.  You'll get better utilization shown  
in Task Manager, but a lot of that time will be wasted, not making forward  
progress on your actual processing.

Better would be to update the GUI only every N iterations of your  
processing, where you pick N so that the GUI is in fact updated only every  
500 or 1000 ms or so.  But even choosing N arbtirarily as, for example,  
100 or 500 or 1000, is likely to show a noticeable improvement in  
processing time (maybe not a huge improvement, but at least measurable).

Depending on how much information you need to pass to the GUI, it may not  
actually be a bad idea to have the GUI poll the progress based on a timer  
as you were doing before.  For example, if the progress can be  
encapsulated in a single 32-bit integer, you could just make that a  
volatile field and the GUI would be able to examine it for the purpose of  
updating progress without a need for any synchronization with the  
processing thread.  Then you can use a timer to control the actual  
updating, saving the need to include some arbitrary reduction factor in  
the processing thread.  This would make the processing code simpler, and  
would make the timing of updates more reliable, rather than depending on  
some arbitrary, empirically-determined fixed iteration count for updates.

The key here is to make sure you're polling the processing thread  
correctly.  If that was a problem before in your code, then it's likely  
you were doing something inefficient in the polling.  Without any sample  
code showing what you're doing, it's impossible to say what might have  
been the problem.  But done correctly, a timer-based polling scheme should  
work fine and if you know you need to update the UI every N milliseconds,  
then it's likely the right thing to do.  Polling's only bad _most_ of the  
time.  :)

Pete