Perché Thread.Sleep() prima di SerialPort.Open e Close?

Question

Ho notato codici di esempio che ho letto su SerialPort in chiusura e in apertura dove le persone aggiungevano Thread.Sleep (1000) prima di SerialPort.Open() e Close(). Mi piace il seguente:

Thread.Sleep(1000); 
serialPort1.Open(); 
/* some code */ 
Thread.Sleep(1000); 
serialPort1.Close(); 

Non riesco a trovare alcuna spiegazione da nessuna parte. Perché le persone bloccano la porta seriale usando Thread.Sleep prima che diventi Open o Close? E 'per un certo scopo temporale? Dovrei inserire un Thread.Sleep ogni volta che leggo o scrivo anche su Serial Port?

Answer 1

Quando si apre una porta, la classe SerialPort attiva un nuovo thread sotto il cofano che è responsabile (tramite la funzione API di Windows WaitCommEvent) per attendere l'attività della porta seriale (ad esempio i dati arrivati) e attivare gli eventi appropriati sul proprio gestori. Ecco perché eventi come DataReceived si verificano effettivamente su un thread secondario.

Quando si chiude la porta, la chiamata Close() restituisce immediatamente ma è necessario del tempo prima che il thread secondario ruoti verso il basso.

Se si tenta di riaprire la porta troppo rapidamente dopo aver chiamato Chiudi e il thread non è ancora stato ruotato, l'istanza SerialPort non è in uno stato in cui è possibile iniziare una nuova connessione.

Nota i MSDN documentation for SerialPort.Close stati:

La pratica migliore per ogni applicazione è di aspettare per una certa quantità di tempo dopo aver chiamato il metodo Close prima di tentare di chiamare il metodo Open , come la porta non può essere chiuso all'istante.

È possibile tenere traccia di quando si è chiusa la porta e prima di riaprirla assicurarsi che sia trascorso un certo timeout arbitrario.

Non c'è bisogno di dormire prima di letture/scritture, anche se un paio di stranezze da tenere a mente:

• Leggi può restituire meno byte che si chiede per
• A volte l'evento DataReady non si attiva
• ReadTimeout can be buggy

tenere a mente la classe SerialPort in .NET BCL si basa ancora sul sottostante API Win32, e io non credo che è ottenuto un sacco di amore da Microsoft sinc e l'implementazione iniziale.

Per ulteriori informazioni si veda:

• http://www.innovatic.dk/knowledg/SerialCOM/SerialCOM.htm#SerialPortEvents

• http://social.msdn.microsoft.com/Forums/en/netfxbcl/thread/f334ecce-eca3-46fd-8b65-27c02a1d4fea#10dae30d-bc75-49bb-a669-79399e58e1cc

• SerialPort class occasionally hangs on Dispose

Answer 2

Può esistere una sola connessione aperta per oggetto SerialPort. La best practice per qualsiasi applicazione è di attendere un po 'di tempo dopo aver chiamato il metodo Close prima di tentare di chiamare il metodo Open, in quanto la porta potrebbe non essere chiusa all'istante.

Dai un'occhiata a questo link.

Answer 3

Ho eseguito alcuni programmi di I/O seriale in C# e non credo di aver mai aggiunto dormi del genere. Non ho riscontrato effetti negativi (con l'avvertenza che le mie app non hanno mai provato ad aprire e chiudere la porta seriale in rapida successione)

Non si dovrebbe assolutamente dormire prima di leggere o scrivere.