C# 中的线程与计时器

Question

I have two implementations of checking for data coming:

Using System.Timers.Timer :

public void startTimer()
{
    try
    {
         System.Timers.Timer timer = new System.Timers.Timer(1);
         timer.AutoReset = true;
         timer.Elapsed += new ElapsedEventHandler(commStart);
         timer.Enabled = true;
         timer.Start();
    }
    catch(Exception ex){}
}

private void commStart(){object sender, EventArgs eArgs}

Using Thread :

public void startThread()
{
   Thread threadGeneralComm = new Thread(new ThreadStart(commStart));

   threadGeneralComm.Start()
}

private void commStart()
{
   while(true)
   {
       // checking data
       Thread.Sleep(1);
   }
}

So you can see, both of the implementation ways, it will check for data and wait for 1 millisecond. People are complaining to me that using Timer is worse than using Thread, and using a Thread is 10 times faster. Is that the case?

Answer 1

Both options are poor. They are polling methods and so will use CPU for no reason when there is no data.

If you can't use an event driven approach then you should look for a solution based on a blocking queue.

Answer 2

Windows applications are based on event driven architecture. Mouse move, key press, showing UI, moving window, resizing etc all of them are events. When there is an event to your application, windows assign that event to something called Application Queue and the window application shall have continous loops for getting the event from application queue, and process the event using the Dispatcher.

In this way, a TIMER is an event, when registered, the OS will put the timer message on the application queue so that the application can process the timer. The TIMER always works on the UI thread. So it is up to the operating system whether to put the TIMER event on the app queue or not. When the OS is too busy, you may miss your timer events.

A thread has an independent execution context, which is guaranteed to be executed.

Answer 3

The difference between the solutions
The main difference between the solutions is that the timer one will be called every millisecond, while the single thread solution will wait one millisecond between every data check.

In the timer solution, the data checking will happen in parallel - every callback is done on a different thread on the thread pool.

For example, when using a timer every with 10ms interval and the callback method takes 20ms to process, there'll be several active callbacks on multiple threads from the threads pool.

Single thread is better (in this case)
Assuming that in your example the processing takes more than 1ms, it explains why it is much slower than having a single thread.

I assume that there might be a better solution than this - using a DB trigger, some event or callback... But if the only way to get the information is by actively checking the data then using the single thread solution is better.

Answer 4

If you are waiting for Data to come to comes as a file, you can use FileSystemWatcher

Polling is always resource intenstive, better to use Hollywood Principle Design Pattern