fil vs minuterie en C#

Question

J'ai deux implémentations de la vérification des données à venir:

Utilisation 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} 

Utilisation Thread:

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

    threadGeneralComm.Start() 
} 

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

Vous pouvez le voir, les deux façons de mise en œuvre, il va vérifier les données et attendre 1 milliseconde. Les gens se plaignent que l'utilisation de Timer est pire que l'utilisation de Thread, et l'utilisation d'un Thread est 10 fois plus rapide. Est-ce le cas?

Answer 1

Les deux options sont mauvaises. Ils sont des méthodes d'interrogation et utiliseront donc le processeur sans aucune raison en l'absence de données.

Si vous ne pouvez pas utiliser une approche événementielle, vous devez rechercher une solution basée sur une file d'attente de blocage.

Answer 2

Les applications Windows sont basées sur une architecture pilotée par les événements. Déplacement de la souris, appui sur la touche, affichage de l'interface utilisateur, déplacement de la fenêtre, redimensionnement, etc. sont tous des événements. Lorsqu'il y a un événement dans votre application, Windows affecte cet événement à une application appelée Application Queue et l'application de fenêtre doit avoir des boucles continues pour obtenir l'événement de la file d'attente d'application et traiter l'événement à l'aide de Dispatcher. De cette manière, un TIMER est un événement, lorsqu'il est enregistré, le système d'exploitation placera le message de temporisateur dans la file d'attente de l'application afin que l'application puisse traiter le temporisateur. Le TIMER fonctionne toujours sur le thread UI. Il appartient donc au système d'exploitation de mettre ou non l'événement TIMER dans la file d'attente de l'application. Lorsque le système d'exploitation est trop occupé, vous risquez de manquer vos événements de minuterie.

Un thread a un contexte d'exécution indépendant, dont l'exécution est garantie.

Answer 3

La différence entre les solutions
La principale différence entre les solutions est que la minuterie ne sera appelé à chaque millième de seconde, tandis que le seul fil solution attendra une milliseconde entre chaque vérification des données.

Dans la solution de minuterie, la vérification des données se fera en parallèle - chaque rappel est effectué sur un thread différent sur le pool de threads. Par exemple, lorsque vous utilisez une minuterie avec un intervalle de 10 ms et que la méthode de rappel prend 20 ms à traiter, il y a plusieurs rappels actifs sur plusieurs threads du pool de threads.

fil simple est mieux (dans ce cas)
En supposant que dans votre exemple, le traitement prend plus de 1ms, il explique pourquoi il est beaucoup plus lent que d'avoir un seul fil. Je suppose qu'il pourrait y avoir une meilleure solution que celle-ci - en utilisant un déclencheur DB, un événement ou un rappel ... Mais si la seule façon d'obtenir l'information est en vérifiant activement les données puis en utilisant la solution de thread unique est meilleur.

Answer 4

Si vous attendez pour les données à venir Comes comme un fichier, vous pouvez utiliser FileSystemWatcher

Polling est la ressource toujours intenstive, il vaut mieux utiliser Hollywood Principle Design Pattern