Click here to Skip to main content
15,880,427 members
Please Sign up or sign in to vote.
0.00/5 (No votes)
See more:
Hi,

I have a query here which is almost a week back I faced. This is all to get the continuous data from a hardware to C# in call back methods. Transfer rate is 1/2 millisecond for each packet.

In C# winforms 3.5, I have created a Thread (Asynchronous) with IsBacground property as true. It was running fine.

As my immediate thought, I took BagroundWorker thread from tool box and running as CallAsync nature. This is also running fine.

Here my observation is , Bagound worker thread is running so fast when compared to system.Threading. What might be the reason ? Please explain the concept behind it.
Posted

The only reason could be abuse of technology. If cannot run faster. There is something you did wrong. I have no information on your code to give any detail. :-)

—SA
 
Share this answer
 
Comments
SKOTAJI 6-May-11 13:48pm    
I have done all these in a sample. I dont think there is any wrong.

Also, I would like to know the dif b/w Timer / Thread (Is baground) / Worker thread.
Sergey Alexandrovich Kryukov 6-May-11 14:00pm    
If you did not do anything wrong (how do you know that), what's wrong?

There is no reason for System.Threading.Thread to be slower than Background worker simply because the thread behind is exact same thing. Well, maybe Backrgound/Foreground makes some difference in your case and is different in your two experiments. You can make them the same and compare -- interesting to see. We can discuss your code and try to understand where is the difference in performance. I think the issue is how clean your experiment is.

Timer: get rid of them if possible, by many reasons, always prefer thread. If you doubt if thread is applicable (doubt about incorrect timing, waste of CPU time?), maybe I can give you a better idea. Thread vs. Worker thread? OK, what's "worker thread"? This is not a special term for something certain, just a thread. Sometime people call "worker thread" a thread which is not the same as the one of application entry point, sometime -- non-UI thread, which is usually the same. There is not one vs. another. Or you mean something else? Then explain.

--SA
SKOTAJI 6-May-11 14:39pm    
Here my concern is - The background thread is comes with assembly system.dll and with componentModel namespace. So, I think its no where related to Winforms. If we use system.Thread I have to specify priority. Otherwise it slows down when CPU requires. But, in my case even though I have priority to thread .. it appears slow on continuous stream of data. Is my observation is true ? .. Justify it.
Sergey Alexandrovich Kryukov 6-May-11 14:57pm    
You're right about Component Model (one of the weakest parts in .NET in my opinion) and Forms (using component model, but the a thread itself is not related to Forms). The thread should not really depend on Forms. Even Dispatcher works the same way in Forms and WPF (basically, you always need to know Dispatcher if you use thread with UI). In brief and roughly speaking, BackroundWorkier is a thread for lamers (I no way want to say it should not be used).

Now, it's the best not to touch priority. My question is: does you thread use any kind of spin wait (a loop doing nothing really useful but checking some condition, or doing some polling)?

Most of the performance problem with threads is due to incorrect using (or not using) of wait states where the thread consumes zero CPU time until awaken by the condition (timeout, by synchronization primitive like lock or event wait handle, Abort or Interrupt). Failure to using though is a usual reason of performance leak.

--SA
SKOTAJI 6-May-11 22:13pm    
Yes. I agree with you. I have not used Thread with spin / wait. But, here the spectrum data will come for 1/2 millisecond at very specific level. No need to wait the thread. Okay, let me try with this wait option also as you said .. I will discuss with you soon on this.
Try this [^]wiki link. It has useful informaion
-NDK
 
Share this answer
 
Comments
fjdiewornncalwe 8-Dec-11 13:58pm    
The OP is far beyond that already.

This content, along with any associated source code and files, is licensed under The Code Project Open License (CPOL)



CodeProject, 20 Bay Street, 11th Floor Toronto, Ontario, Canada M5J 2N8 +1 (416) 849-8900