Quindi Thread.Sleep() non è valido (http://msmvps.com/blogs/peterritchie/archive/2007/04/26/thread-sleep-is-a-sign-of-a-poorly-designed-program.aspx).Alternative a Thread.Sleep() per simulare le pause
Esiste un'alternativa raccomandata alla simulazione di una pausa nell'esecuzione di un programma? Ad esempio un ciclo? Anche se suppongo che questo comporta un sacco di overhead nella inizializzazione delle variabili, controllando lo stato bool, ecc
Grazie
Credo Raymond Chen ha raccomandato di impostare la priorità di filo inferiore
http://blogs.msdn.com/oldnewthing/archive/2009/07/27/9849503.aspx
Non capisco perché tu voglia fermarti ogni tanto. Perché non fare semplicemente il lavoro a bassa priorità? Quando ci sono cose più importanti da fare, il thread in background smetterà di fare qualunque cosa stia facendo. Quando c'è una CPU disponibile, il thread in background farà il suo gioco il più velocemente possibile (fino a quando arriva qualcosa con priorità più alta).
La sua raccomandazione riguarda il "terzo" uso del sonno - per rallentare l'operazione e non consumare troppo tempo della CPU. La domanda riguarda la simulazione di pause, che è l'uso perfetto per Thread.Sleep. Il secondo uso, di cui parla l'articolo di una risposta diversa, è il polling, e questo è male. – configurator
Se stai aspettando che si verifichi un codice o un evento, puoi utilizzare le maniglie di attesa.
è possibile utilizzare anche waithandles al posto di Thread.Sleep (tempo) per eseguire la logica periodica. – Alan
Non sono d'accordo con la valutazione che Thread.Sleep() è "cattivo". Dipende dalla situazione.
In un programma in modalità console, potrebbe essere perfettamente appropriato dormire il thread se si sta aspettando qualcosa. Forse anche in un ciclo: controlla le condizioni, dormi un po 'se non è soddisfatto, ripeti.
In un programma grafico, tuttavia, normalmente non si dorme sul thread principale (GUI). Questo perché le interfacce GUI di questi giorni sono progettate con un singolo thread interattivo. Se dormi su quel thread, l'intera GUI sembrerà "bloccata" per il tempo che stai dormendo. Una situazione migliore potrebbe essere quella di utilizzare una sorta di timer (tutti i framework della GUI hanno un tale concetto).
Una cosa che fai non vuoi fare è scrivere un ciclo che controlla continuamente che alcune condizioni siano vere, senza nemmeno dormire. Ciò causerà una CPU fino al 100% perché la CPU vuole eseguire il proprio lavoro il più velocemente possibile. Non solo è inaspettato da un punto di vista dell'utente, ma è scortese perché tale attività può far morire di fame il processo che in realtà stai aspettando un numero sufficiente di cicli per ottenere il lavoro !
Ecco a cosa servono le primitive di sincronizzazione. Questo è il punto cruciale del blogpost. – ebo
Ma "simulare una pausa nell'esecuzione di un programma" non è ciò che sono per le primitive di sincronizzazione. Questo è il punto della ** domanda **. –
Ma stai scrivendo è ok per usarlo per la comunicazione, che non lo è. – ebo
Da quello che hai detto, stai cercando di simulare una pausa in esecuzione.
Thread.Sleep è perfettamente valido per quello. Anche l'articolo collegato inizia con:
Thread.Sleep ha il suo uso: simulare lunghe operazioni durante il test/debug su un thread MTA.
Se si sta solo andando a simulare una pausa (come per scopi di test), penso che Thread.Sleep è un approccio perfettamente valido. D'altra parte, se si è in realtà in attesa di qualcosa, sarebbe meglio una sorta di meccanismo di segnalazione thread-safe (controllare i tipi che ereditano WaitHandle).
simulando una pausa
"Simulazione" suona come qualcosa che si potrebbe fare solo in debug. Thread.Sleep dovrebbe andare bene.
Il problema principale di Sleep è che in genere è necessario attendere che si verifichi qualcosa di specifico anziché attendere un ritardo arbitrario.
L'altra cosa a cui fare attenzione è chiamare Thread.Sleep da un thread dell'interfaccia utente, che renderà l'interfaccia utente non risponde. È meglio disabilitare le parti dell'interfaccia utente con cui non si desidera interagire con l'utente e quindi utilizzare un controllo Timer per implementare il ritardo.
Questo è un suggerimento perfetto! Ha funzionato nel modo in cui lo volevo nel mio programma. Ho appena aggiunto un altro timer per aspettare un tempo specificato prima di passare a un'altra parte del programma. – AndHeCodedIt
Io uso le System.Timers:
http://msdn.microsoft.com/en-us/library/system.timers.timer.aspx
Mentre l'articolo stesso è discutibile, sono d'accordo con la sentenza di partenza, che affronta la vostra preoccupazione
Thread.Sleep ha il suo uso : simulazione delle operazioni lunghe mentre test/debug su un thread MTA. In .NET non c'è altro motivo per usare lo .
credo che è quello che si sta chiedendo circa (la simulazione di pause) ed è l'uso principale di Thread.Sleep()
sarei pronto a scommettere che nella maggior parte dei casi in cui un programmatore pensa di utilizzando Thread.Sleep(), un semplice codice che utilizza event s funzionerebbe molto bene.
Voglio invertire quell'articolo, ma non posso. StackOverflow ha rovinato il resto di Internet per me. – MusiGenesis
Desidero che l'articolo spieghi perché il 100% della CPU utilizzata in un ciclo continuo di lavoro sia un'alternativa preferenziale a Thread.Sleep (1). – StingyJack