Program gets sluggish when jumps between threads

[surabhi_bhosale]

Hello!
 There are 4 threads running in this code

• Thread 1- to continuously display the time on GUI and update a variable xax=Timer() with time elapsd since the tool was started
• Thread 2- to send data on COM port or ethernet
• Thread 3- to calculate vibration values on run and plot the same
• Thread 4- to calculate temperature values on run and plot the same.

Before starting these threads, the temp and vibration arrays are filled by reading from a text file.

The problem faced by me is, the CPU usage rises upto 75% suddenly when i launch the .exe file for this project. Also the RAM usage increases to updto 60-70% thus making the GUI very slow and sluggish
Also the varibale, xax=Timer() skips some values and thgus it affects the temp and vibration plots from thread 2 and thread 4

i have attached my .c file for refrence

please suggest a solution to this issue.

[RobertoBozzolo]

Frankly speaking, 46 pages of unreadable code are too much for the time I can spend on the forum. The next time you post something, limit the code to the relevant one only (20 pages of file parsing code are useless here!), and post directly the source file, not the pdf version which cannot be imported as-is in a code editor for examination.

Having said this, CPU usage is affected by a series of factors that are all relevant. A good scenario could be this one:

• Set CVI sleep policy to Sleep some or better Sleep more in Options >> Environment dialog. This affects all threads and permits CVI to release system resources when no longer needed
• Keep this option for the main thread, which should be responsible to handle the user interface
• Call SetSleepPolicy () for the remaining threads setting it to Sleep some or to Do not sleep depending on how the thread is critical
• Keep threads as short as possible removing all unnecessary code. In particular, you should remove all UI update code from the spawned threads and move it to the main thread. PostDeferredCall can be used in this respect, as well as queues

Simply setting a while (1) in the threads is not reccommended since it does not release time for other tasks: alternative solutions are to use timers or loops with a SyncWait embedded, carefully designing how much processor time is needed for each task.

Finally, a overall CPU usage value gives little informations: since you are probably running on a multiprocessor machine, you should examine each core activity and see how modifications in the code affects it.

[RobertoBozzolo]

Some additional notes after a fast code read:

• You are calling QuitUserInterface () in several places, even inside threads: while calling it inside a thread has no effect on the main thread, I would reccommand that you try handling anomalies in a few places, to guarantee that each time all allocated resources are correctly disposed of. In this respect, threads should issue some messaging to the main thread to inform of an exception and let the main thread terninate all the tasks
• You are defining independent thread pools for each thread, thus it's illogic to wait for thread completion inside the default thread pool; additionally, you are not disposing of thread pools at program end
• Setting the debugging level to Extended in Build options dialog will help you understand how many system resources were allocated that you have not released after program terminates
• I wonder if all file parsing could be simplified using IniFile instrument. Additionally, the code is full of unnecessary loops that only run once (e.g.  for (i = tu5; i <= tu5; i++) )

[hendra@ngms]

Some general comments on writing threaded apps, from somebody who writes 20,000 LOC mutli-threaded applications:

1.  It is best practice to put things that are repetitive, like screen updates, in threads, so that the event handler is never blocked.

2.  Most Important:  A well written thread spends 99+% of its time idle -- put in as much Delay() or Sleep() as possible -- for screen updates, you might need to cycle the thread no more than twice a second.  Even if some processing thread has to test a condition every 20 milliseconds, it can still be idle for 99% of the time.

3.  Avoid having a lower than Main() thread launch another thread -- can be done, not very clean.  Better to pass data using common memory from one running thread to another. 

4.  Use semaphores to block activity, flags to initiate activity.

5.  Use a boolean in a permanent thread while() statement, so you can kill the thread later.

6.  Gracefully kill everything, and close files in your QuitUserInterface() function.

7.  Your default thread pool will contain 10 or more threads.  You don't always have to create a thread pool.  If you do, do it once, for the number of threads you need.

8.  Transient threads are fine, but you do pay a price for context switching.  It is often better to have a permainent thread that periodically looks for a state change to do some work.

9.  Always keep in mind what the event handler is doing, how busy it is, how it might become blocked.  This is where sluggishness happens.

10.  Daughter threads should not issue modal dialog boxes.  There are special considerations to make modal dialogs thread safe.

11.  Two threads can call the same function at the same time.  Overlapping execution of the same code block can have very unpredictable results.  If two threads need to do something like format and write to a file, it is safest to create two identical functions with different names.  RAM is cheap.

12.  Use malloc() with extreme care.  Personally, I never use it.  Again, RAM is cheap -- one can manage memory needs without using malloc().

[surabhi_bhosale]

Thank you.
iu have used your commnets in the code..Its working better now!