System.Timers.Timer vs System.Threading.Timer

Question

Ultimamente ho controllato alcuni dei possibili timer, e gli Threading.Timer e Timers.Timer sono quelli che mi sembrano necessari (poiché supportano il raggruppamento dei thread).

sto facendo un gioco, e ho intenzione di utilizzare tutti i tipi di eventi, con diversi intervalli, ecc

Quale sarebbe la migliore?

Answer 1

Questo articolo offre una spiegazione abbastanza completo:

"Comparing the Timer Classes in the .NET Framework Class Library" - disponibile anche as a .chm file

La differenza specifica sembra essere che System.Timers.Timer è orientata verso le applicazioni multithread ed è quindi thread-safe tramite la sua proprietà SynchronizationObject , mentre System.Threading.Timer ironicamente non è sicuro per i thread pronto all'uso.

Non credo che ci sia una differenza tra i due in quanto riguarda quanto piccoli possono essere gli intervalli.

Answer 2

Nel suo libro "CLR via C#", Jeff Ritcher scoraggia utilizzando System.Timers.Timer, questo timer è derivato da System.ComponentModel.Component, permettendo così di essere utilizzato in un'area di progettazione di Visual Studio. In modo che sarebbe utile solo se si desidera un timer su una superficie di progettazione.

Preferisce utilizzare System.Threading.Timer per attività in background su un thread di thread.

Answer 3

System.Threading.Timer è un semplice timer. Ti richiama su un thread pool di thread (dal pool di worker).

System.Timers.Timer è un System.ComponentModel.Component che include uno System.Threading.Timer e fornisce alcune funzionalità aggiuntive utilizzate per l'invio su un determinato thread.

System.Windows.Forms.Timer invece esegue il wrapping nativo message-only-HWND e utilizza Window Timers per generare eventi nel ciclo di messaggi di HWND.

Se la vostra applicazione non ha alcuna interfaccia utente, e si desidera che il più leggero e polivalente timer .Net possibile, (perché si è soddisfatti capire il proprio threading/invio), allora System.Threading.Timer è buono come si arriva in il quadro.

Non sono completamente chiaro quali sono i problemi di "non thread safe" con System.Threading.Timer. Forse è solo stessa ha chiesto in questa domanda: Thread-safety of System.Timers.Timer vs System.Threading.Timer, o forse tutti significa proprio questo:

1. è facile scrivere condizioni di gara quando si utilizza i timer. Per esempio. vedi questa domanda: Timer (System.Threading) thread safety

2. re-entrancy delle notifiche timer, dove il vostro evento timer può attivare e richiamare una seconda voltaprima di aver finito di elaborare il primo evento . Per esempio.vedi questa domanda: Thread-safe execution using System.Threading.Timer and Monitor

Answer 4

ho trovato un breve confronto MSDN

Il Framework .NET include quattro classi denominate Timer, ognuno dei quali offre diverse funzionalità:

System.Timers.Timer , che genera un evento ed esegue il codice in uno o più event sink a intervalli regolari. La classe è destinata a per l'utilizzo come componente basato su server o servizio in un ambiente multithreaded; non ha interfaccia utente e non è visibile in fase di runtime.

System.Threading.Timer, che esegue un singolo metodo di callback su un thread pool di thread a intervalli regolari. Il metodo di callback è definito quando il timer è istanziato e non può essere modificato. Come la classe System.Timers.Timer, questa classe è concepita per essere utilizzata come componente del server o del servizio in un ambiente con multithreading; it non ha interfaccia utente e non è visibile in fase di runtime.

System.Windows.Forms.Timer, un componente Windows Form che genera un evento ed esegue il codice in uno o più sink di evento a intervalli regolari . Il componente non ha un'interfaccia utente ed è progettato per l'uso in un ambiente a thread singolo.

System.Web.UI.Timer, un componente ASP.NET che esegue postback di pagine Web asincrone o sincrone a intervalli regolari.

Answer 5

Le due classi sono funzionalmente equivalenti, tranne che System.Timers.Timer ha un'opzione per richiamare tutti i suoi callback timer di scadenza attraverso ISynchronizeInvoke modificando SynchronizingObject. In caso contrario, entrambi i timer richiamano i callback di scadenza sui thread del pool di thread.

Quando si trascina un System.Timers.Timer su una Windows Form di progettazione, Visual Studio imposta SynchronizingObject all'oggetto forma, che fa sì che tutti i callback di scadenza per essere chiamato sul thread dell'interfaccia utente.

Answer 6

Da MSDN: System.Threading.Timer è un timer semplice e leggero che utilizza i metodi di callback ed è servito dai thread del pool di thread. Non è consigliato per l'uso con Windows Form, perché i suoi callback non si verificano sul thread dell'interfaccia utente. System.Windows.Forms.Timer è una scelta migliore per l'utilizzo con Windows Form. Per la funzionalità di timer basata su server, potresti prendere in considerazione l'utilizzo di System.Timers.Timer, che genera eventi e presenta funzionalità aggiuntive.

Source

Answer 7

Una differenza importante non elencati qui sopra, che potrebbe prendere fuori è che System.Timers.Timer ingoia silenziosamente eccezioni, mentre System.Threading.Timer non lo fa.

Ad esempio:

var timer = new System.Timers.Timer { AutoReset = false }; 
timer.Elapsed += (sender, args) => 
{ 
    var z = 0; 
    var i = 1/z; 
}; 
timer.Start(); 

vs

var timer = new System.Threading.Timer(x => 
{ 
    var z = 0; 
    var i = 1/z; 
}, null, 0, Timeout.Infinite); 

Answer 8

System.Timers.Timer sembra essere deprecato con .NET Core e ASP.NET core. Quindi prova a usare System.Threading.Timer in future app.

---

EDIT: OK, mi permetta di essere più preciso:

Con il nuovo .NET Framework core, Microsoft interrotto alcune tecnologie di .NET Framework. Per capirlo: .NET Core è un framework totalmente nuovo - riscritto, multipiattaforma, ecc. Non voglio approfondire qui in dettaglio - per favore leggi lo .NET Blog.

Sul blog c'è un buon articolo sul porting su .NET Core che spiega anche le difficoltà che si possono raggiungere. Una parte di questo è usare lo .NET Portability Analyzer Visual Studio Add-In e correggere gli errori che si ottengono.

Per la classe System.Timers.Timer, ha detto, che .NET Framework, versione = v4.6.2 è supportato, ma .NET Core Version = v5.0 e .NETPlatform, Version = v5.0 non è. Modifiche consigliate: Use System.Threading.Timer.

Quindi mi sembra che lo System.Timers.Timer sia andato per .NET Core.

P.S .: Ma potrebbe tornare - Microsoft ha annunciato che desidera apportare alcune modifiche a CoreCLR (il nome del framework che si utilizza per .NET Core) per semplificare lo sforzo di porting.