threading weirdness

  • Thread starter Thread starter Stephan Steiner
  • Start date Start date
S

Stephan Steiner

Hi

My application is using several threads at once: the GUI thread, a timer, a
thread to receive packets (which is blocked most of the time using a
ManualResetEvent), and a thread to process received packets (packet
processing is quite complex, so I put received packets in a queue, and have
another thread clear out the queue. Direct reception and processing would
lead to a lot of dropped packets because the receive buffer isn't cleared
quickly enough).
The thread to process received packets is running at below normal priority
in order not to disturb the timer and reception thread (it's important that
those get the cpu time they need.. which isn't much as during reception
phase the cpu load (measured via XCPUScalar) stays below 25%). However, if I
have a lot of incoming packets, the receiver thread will eventually go back
to sleep (waiting for the manualresetevent to be set again), whereas the
processing thread is still working. And that's where the weirdness starts.
The application seems to choose a CPU load at random. It can happen that
during the packet processing phase, the cpu load is 0 % (but it's still
processing), and then I get every value between 0% and 41%, and sometimes
very high values (87 - 97%). Needless to say that if the CPU load is high,
processing is done a lot quicker but wha confuses me is that a thread,
regardless of its priority is supposed to use up whatever resources
available. If there are several idle threads (I don't touch the pda during
the processing phase, so there should be no GUI redraws) and an idle
priority thread with a lot of work to do, the latter should still end up
eating up all the CPU time, should it not? At least that's how it works on
the PC. I have the same application (with minimal changes) running on the
PC, where it behaves as I think it should. The low priority procesing thread
will effectively use up the available CPU time until it has processed every
packet there is to process.

So, I'm wondering if there's any fundamental difference between thread
priorities on Windows XP and Windows CE.NET (Windows Mobile 2003) and why my
application is not using the same amount of cpu time when I run the exact
same test multiple times.

Stephan
 
Alex

I don't use any mutexes any critical sections should be limited (basically
the only thing I could imagine is doing a ManualResetEvent.Set/Reset at the
same time a ManualResetEvent.WaitOne is executed, but I actually, ResetEvent
updates lead to a GUI update so I'd see if the thread waiting for the
resetevent preemts the thread setting or resetting the event, and once the
event has been reset, the thread waiting for it goes to sleep, leaving the
other to do its task). If one of my threads would preempt another, it would
finish processing sooner, and then go to sleep (the timer thread, which is
not influenced by all this interaction as it seems, would make sure of that
even in case the processing thread would be incapacitated to shut down the
reception), leaving the CPU resources to the thread still running.

Other than that, interactions with the GUI thread are done via
Control.Invoke so that the triggered GUI updates won't interfere with the
GUI's general workings.
Interestingly though, once packet processing has completey, there's a small
section running within the GUI domain which is quite resource consuming
(basically stats generation which are then shown in the GUI), and this
processing actually uses all available resources (you can see a short peak
in CPU usage until the GUI update is completed).

Stephan
 
Back
Top