La documentazione MSDN per ManualResetEventSlim statiManualResetEventSlim raccomandati tempo di attesa
È possibile utilizzare questa classe per prestazioni migliori di
ManualResetEventquando i tempi di attesa dovrebbero essere molto breve.
Quanto è "molto breve"? A che punto il vantaggio dell'utilizzo di un oggetto kernel con un ManualResetEvent supera l'overhead di istanziarlo?
Questo è quello che ho trovato e mi piacerebbe che qualcun altro per convalidare questa, ma questo è quello che ho trovato durante la lettura del Reference Source for ManualResetEventSlim
ManualResetEventSlim
Si sta tentando di dormire solo e resa sulla base del numero di di processori e di fare un sonno estremamente breve - 1ms o 0ms a seconda del suo attuale indice di rotazione. Se non è stato ancora abbastanza tempo, verrà ripristinato l'utilizzo di una nuova versione aggiornata del timeout originariamente inoltrato.
Il passaggio di 0 per Thread.Sleep allevia la sua porzione di tempo.
ManualResetEvent
Esso utilizza WaitHandle e chiama i metodi nativi per gestire in attesa che il tempo specificato. Sfortunatamente, non sono in grado di vedere cosa sta facendo.
mia conclusione
"Very Short" significa pochi millisecondi.
EDIT: Ho appena trovato questi che hanno un sacco di informazioni:
La scala dalla cache della CPU alla RAM e al kernel è approssimativamente logaritmica. Supponiamo che tu possa fare 400 cicli usando la cache della CPU o 20 cicli della CPU usando la lettura/scrittura della RAM o 1 operazione del kernel. I numeri dipenderanno dall'hardware, è solo una stima.
Se si ritiene che i tempi di attesa massimi siano inferiori a 6-15 ns (~ 20-50 cicli CPU @ 3GHz) rispetto al tempo di attesa ridotto.
Per me, "molto breve" è piuttosto insignificante. La mia regola è che se mi aspetto che l'evento sia impostato per la maggior parte del tempo (cioè non aspetto di aspettare), allora userò 'ManualResetEventSlim'. Altrimenti userò 'ManualResetEvent'. Se stai scrivendo un'applicazione sensibile alle prestazioni, dovresti testare il tuo codice con entrambi per determinare se c'è qualche differenza. Se non contate i microsecondi, probabilmente è una perdita di tempo preoccuparsi di quale sia più veloce. –
"Molto breve" in questo contesto significa da decine a centinaia di microsecondi. La versione snella attizza con l'aspettativa che l'altro thread rilascerà il blocco in meno tempo rispetto a un paio di interruttori di contesto. – doug65536