System.Timers.Timer vs System.Threading.Timer

Ultimamente ho verificato alcuni dei possibili timer System.Threading.Timere System.Timers.Timersono quelli che mi sembrano necessari (poiché supportano il pool di thread).

Sto realizzando un gioco e intendo utilizzare tutti i tipi di eventi, con intervalli diversi, ecc.

Quale sarebbe il migliore?

Questo articolo offre una spiegazione abbastanza completa:

" Confronto delle classi timer nella libreria di classi .NET Framework " - disponibile anche come file .chm

La differenza specifica sembra essere System.Timers.Timerorientata verso applicazioni multithread ed è quindi sicura per i thread grazie alle sue SynchronizationObjectproprietà, mentre System.Threading.Timerironicamente non è pronta all'uso per i thread.

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

System.Threading.Timerè un semplice timer. Richiama un thread del pool di thread (dal pool di lavoro).

System.Timers.Timerè un a System.ComponentModel.Componentche avvolge a System.Threading.Timere fornisce alcune funzionalità aggiuntive utilizzate per l'invio su un thread specifico.

System.Windows.Forms.Timeravvolge invece un HWND nativo solo per messaggi e utilizza i timer finestra per generare eventi in quel ciclo di messaggi HWND.

Se la tua app non ha un'interfaccia utente e desideri il timer .Net più leggero e generico, (perché sei felice di capire il tuo threading / invio), allora System.Threading.Timerè buono come si ottiene nel framework.

Non sono del tutto chiaro quali siano i presunti problemi "non thread-safe" System.Threading.Timer. Forse è esattamente lo stesso di questa domanda: thread-safety di System.Timers.Timer vs System.Threading.Timer , o forse tutti significano semplicemente che:

1. è facile scrivere le condizioni di gara quando si utilizzano i timer. Ad esempio, vedi questa domanda: Timer (System.Threading) sicurezza thread

2. reinserimento delle notifiche timer, in cui l'evento timer può attivarsi e richiamarti una seconda volta prima di completare l'elaborazione del primo evento. Ad esempio, vedere questa domanda: esecuzione thread-safe utilizzando System.Threading.Timer e Monitor

Nel suo libro " CLR Via C # ", Jeff Ritcher scoraggia l'utilizzo System.Timers.Timer, questo timer è derivato System.ComponentModel.Component, permettendogli di essere utilizzato nella superficie di progettazione di Visual Studio. In modo che sarebbe utile solo se si desidera un timer su una superficie di progettazione.

Preferisce utilizzare le System.Threading.Timerattività in background su un thread del pool di thread.

Informazioni da Microsoft su questo (vedi Note su MSDN ):

• System.Timers.Timer , che genera un evento ed esegue il codice in uno o più sink di evento a intervalli regolari. La classe è destinata all'uso come componente basato su server o di servizio in un ambiente multithread; non ha un'interfaccia utente e non è visibile in fase di esecuzione.
• System.Threading.Timer , che esegue un singolo metodo di callback su un thread del 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 è destinata all'uso come componente basato su server o di servizio in un ambiente multithread; non ha un'interfaccia utente e non è visibile in fase di esecuzione.
• System.Windows.Forms.Timer (solo .NET Framework), un componente di 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; viene eseguito sul thread dell'interfaccia utente.
• System.Web.UI.Timer (solo .NET Framework), un componente ASP.NET che esegue postback asincroni o sincroni delle pagine Web a intervalli regolari.

È interessante ricordare che è System.Timers.Timerstato deprecato con .NET Core 1.0, ma è stato nuovamente implementato in .NET Core 2.0 (/ .NET Standard 2.0). L'obiettivo con .NET Standard 2.0 era che dovrebbe essere il più semplice possibile passare da .NET Framework, che probabilmente è la ragione per cui è tornato.

Quando è stato deprecato, si consiglia di utilizzare invece il componente aggiuntivo .NET Studio di portabilità di Visual StudioSystem.Threading.Timer .

Sembra che Microsoft preferisca System.Threading.Timerprima System.Timers.Timer.

NOTA EDIT: 15-11-2018: passo a cambiare la mia risposta poiché le vecchie informazioni su .NET Core 1.0 non erano più valide.

Una differenza importante non menzionata sopra che potrebbe sorprenderti è che System.Timers.Timeringoia silenziosamente le eccezioni, mentre System.Threading.Timernon lo fa.

Per 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);

Ho trovato un breve confronto da MSDN

La libreria di classi .NET Framework include quattro classi denominate Timer, ognuna delle quali offre funzionalità diverse:

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

System.Threading.Timer, che esegue un singolo metodo di callback su un thread del 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 è destinata all'uso come componente basato su server o di servizio in un ambiente multithread; non ha un'interfaccia utente e non è visibile in fase di esecuzione.

System.Windows.Forms.Timer, un componente di 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 asincroni o sincroni delle pagine Web a intervalli regolari.

Le due classi sono funzionalmente equivalenti, tranne quello System.Timers.Timer ha un'opzione per invocare tutti i callback di scadenza del timer tramite ISynchronizeInvoke impostando SynchronizingObject . In caso contrario, entrambi i timer richiamano i callback di scadenza sui thread del pool di thread.

Quando si trascina un oggetto System.Timers.Timernell'area di progettazione di Windows Form, Visual Studio imposta SynchronizingObject sull'oggetto modulo, facendo sì che tutti i callback di scadenza vengano chiamati sul thread dell'interfaccia utente.

Da MSDN: System.Threading.Timerè un timer semplice e leggero che utilizza metodi di callback ed è servito da thread del pool di thread. Non è raccomandato 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à timer basata su server, potresti prendere in considerazione l'utilizzo System.Timers.Timer, che genera eventi e presenta funzionalità aggiuntive.

fonte