Quanto è scalabile System.Threading.Timer?

Question

Sto scrivendo un'app che dovrà essere utilizzata Timers, ma potenzialmente moltissimi di loro.Quanto è scalabile il file System.Threading.Timer classe?La documentazione dice semplicemente che è "leggero", ma non spiega ulteriormente.Questi timer vengono risucchiati in un singolo thread (o pool di thread molto piccolo) che elabora tutti i callback per conto di un Timer, o fa ciascuno Timer ha un proprio thread?

Immagino che un altro modo per riformulare la domanda sia:Com'è System.Threading.Timer implementato?

Answer 1

Lo dico in risposta a molte domande:Non dimenticare che il codice sorgente (gestito) del framework è disponibile.Puoi utilizzare questo strumento per ottenere tutto: http://www.codeplex.com/NetMassDownloader

Sfortunatamente, in questo caso specifico, gran parte dell'implementazione è in codice nativo, quindi non puoi guardarlo...

Tuttavia, utilizzano sicuramente i thread del pool anziché un thread per timer.

Il modo standard per implementare una grande raccolta di timer (che è il modo in cui lo fa internamente il kernel, e sospetto che sia indirettamente il modo in cui finisce la tua grande raccolta di timer) è mantenere l'elenco ordinato in base al tempo fino alla scadenza, quindi il il sistema deve preoccuparsi solo di controllare il prossimo timer che sta per scadere, non l'intero elenco.

Approssimativamente, questo fornisce O(log n) per avviare un timer e O(1) per elaborare i timer in esecuzione.

Modificare:Ho appena guardato il libro di Jeff Richter.Dice (di Threading.Timer) che utilizza un singolo thread per tutti gli oggetti Timer, questo thread sa quando verrà eseguito il timer successivo (ovverocome sopra) è dovuto e chiama ThreadPool.QueueUserWorkItem per i callback come appropriato.Ciò ha l'effetto che se non finisci di servire una richiamata su un timer prima della scadenza della successiva, la richiamata rientrerà in un altro thread del pool.Quindi, in sintesi, dubito che vedrai un grosso problema con molti timer, ma potresti soffrire di esaurimento del pool di thread se un gran numero di essi si attiva con lo stesso timer e/o i loro callback funzionano lentamente.

Answer 2

Penso che potresti voler ripensare il tuo progetto (cioè, se hai tu stesso il controllo sul progetto).Se stai utilizzando così tanti timer che questo è effettivamente un problema per te, c'è chiaramente un potenziale di consolidamento lì.

Ecco un buon articolo di MSDN Magazine di alcuni anni fa che confronta le tre classi di timer disponibili e fornisce alcune informazioni sulle loro implementazioni:

http://msdn.microsoft.com/en-us/magazine/cc164015.aspx

Answer 3

Consolidarli.Crea un servizio timer e chiedi che i timer.Dovrà solo mantenere 1 timer attivo (per la prossima chiamata di scadenza) ...

Affinché questo sia un miglioramento rispetto alla semplice creazione di molti oggetti Threading.Timer, è necessario presupporre che non sia esattamente ciò che Threading.Timer sta già facendo internamente.Mi interesserebbe sapere come sei arrivato a questa conclusione (non ho smontato le parti native del framework, quindi potresti avere ragione).

Answer 4

^^ come dice Danny Puffo:Consolidarli.Crea un servizio timer e chiedilo per i timer.Sarà necessario mantenere solo 1 timer attivo (per la prossima chiamata prevista) e una cronologia di tutte le richieste del timer e ricalcolarlo su AddTimer() / RemoveTimer().