LabWindows/CVI

cancel
Showing results for 
Search instead for 
Did you mean: 

CPU Usage jumps to 100% when using default thread pool

I have an application that has one thread to read the device data over USB and post it via the thread safe queue for the application to plot on a timer callback.
I see the CPU usage jumps to 100% on starting the application and it is the device thread that takes up the CPU. I am using the default thread pool and normal priority.
 
This is the guts of the function to create the thread:
 
   // Create thread safe queues for frame data and frame information
   if (CmtNewTSQ (CMD_QUEUE_LEN, sizeof (unsigned char), OPT_TSQ_AUTO_FLUSH_ALL, &htsqCmd) < 0)
   {
      MessagePopup("Error", "Error creating command thread safe queue");
      return FALSE;
   }
   if (CmtNewTSQ (ECG_QUEUE_LEN, sizeof (short), OPT_TSQ_AUTO_FLUSH_ALL, &htsqECG) < 0)
   {
      MessagePopup("Error", "Error creating ECG data queue");
      return FALSE;
   }
   /* Indicate the threads will be running. */
   bDeviceThreadRunning = 1;
   /* Start the writer thread and install a callback for cleanup */
   /* when the writer thread terminates.                         */
   CmtScheduleThreadPoolFunctionAdv (DEFAULT_THREAD_POOL_HANDLE,
                                     DeviceThreadFunction,
                                     NULL, THREAD_PRIORITY_NORMAL,
                                     DeviceThreadCleanupCallback,
                                     EVENT_TP_THREAD_FUNCTION_END, NULL,
                                     CmtGetCurrentThreadID(), NULL);
  
   SetCtrlAttribute(hECGPanel, ECG_TRACE_TIMER, ATTR_ENABLED, 1);
Any ideas on reducing the CPU load?
0 Kudos
Message 1 of 3
(4,562 Views)

Thread priority only controls how the OS thread scheduler allocates threads to the CPU. Any thread can cause a high CPU load depending on what it is doing. If your thread runs a tight loop or calls a function that runs a tight loop then you would see high CPU usage. But this should not be a problem if your thread is of normal priority because then other normal priority and higher priority threads can preempt your thread - only lower priority threads will be affected. Calling functions like RunUserInterface sometimes cause this behavior (seemingly high CPU usage) because RunUserInterface is basically a loop that is polling for UI and other events.

You should find out which functions your threads are executing when you see this high CPU usage. Sometimes you can workaround this by changing these functions - like replacing RunUserInterface with a loop calling ProcessSystemEvents and Sleep. As I mentioned above, higher than expected CPU usage should not be a problem when it is happening on normal or low priority threads. But if this is really affecting your application/system (doubtful) then you should narrow down the functions your threads are in when you see this problem.

 

Best regards

0 Kudos
Message 2 of 3
(4,542 Views)
I'm more inclined to think that it's your timer control that is causing the CPU load to jump. Timers require increased overhead that is necessary in order to know when to fire the callbacks. (However, Mohan makes a good point that this increased load should not result in decreased performance, since this is a pretty low-priority activity -- that is why UI-based timers are notoriously inaccurate).

However, if you still want to reduce the CPU load, I would recommend eliminating the UI timer. If you are only using it to periodically remove items from the queue, you could accomplish the same goal by instead using the events that are generated by the queue itself. Check out the CmtInstallTSQCallback function.

Luis
NI
0 Kudos
Message 3 of 3
(4,536 Views)