¿Es necesario sincronizar las escrituras/lecturas de .NET SerialPort?

En mi aplicación utilizo la clase .NET SerialPort para leer y escribir datos. La lectura se realiza utilizando el evento DataReceived, supongo internamente en un hilo de ThreadPool. La escritura se realiza mediante el subproceso de interfaz de usuario (WinForms).¿Es necesario sincronizar las escrituras/lecturas de .NET SerialPort?

Me preguntaba si es necesario sincronizar el acceso a la instancia de SerialPort, para que no se produzcan lecturas/escrituras al mismo tiempo. Mi conciencia me dice que debo poner bloqueos a estas llamadas, pero estoy desconcertado ya que todos los ejemplos de C# SerialPort que encuentro en Internet no usan el bloqueo en absoluto.

Fuente

2010-12-10 Mike

Definitivamente debe bloquear. Lo más probable es que los ejemplos que encuentre en Internet estén simplificados en exceso. Intento que sea una regla leer detenidamente la documentación de cualquier ejemplo que intento seguir, en caso de que se haya omitido algo como esto. –

Aquí es un gran hilo sobre el tema, con el autor de la clase SerialPort participar:

MSDN: How does SerialPort handle DataReceived?

Desde mi experiencia, he escrito unas aplicaciones de comunicación en serie docena para su uso como simuladores de hardware, me no bloquear No sabía en ese momento si estaba seguro o no, pero en la práctica, todavía no he tenido un error. (un año de uso casi constante por más de 20 probadores y máquinas de prueba automatizadas) Dicho esto, mis aplicaciones no salen de la compañía; si estuviera escribiendo aplicaciones para el consumo público, podría tener más cuidado.

Fuente

2010-12-10 16:15:10 EJA

Gracias por el excelente e informativo enlace; es un buen hallazgo. Pero creo que se debe tener cuidado de no confiar demasiado en este tipo de detalles de implementación cuando se toman decisiones de diseño como la pregunta original. Es interesante y bueno saber exactamente cómo funcionan las cosas bajo el capó, pero dado que no está documentado oficialmente, no hay garantía de que siga siendo así. La documentación (y las mejores prácticas) recomiendan que bloquees, así que eso es lo que haría, a menos que haya una * desventaja * particular para hacerlo. –

¡Guau, ese enlace definitivamente responde algunas preguntas! Iré con bloqueos, ya que también tendré que manejar escenarios como cerrar y volver a conectar el puerto serie utilizando la misma referencia de miembro en mi clase, por lo que esas cosas tendrán que sincronizarse también – Mike

De la documentación:

estáticos públicos (Shared en Visual Basic) de este tipo (SerialPort) es seguro para subprocesos. No se garantiza que ningún miembro de instancia sea seguro para subprocesos.

Así que debe sincronizar definitivamente su lectura/escritura con bloqueos.

Fuente

2010-12-10 15:39:36 weismat

Sí, sé esa fraseología, es por eso que iba a sincronizar esas llamadas en primer lugar. – Mike

¿Es necesario sincronizar las escrituras/lecturas de .NET SerialPort?

Respuesta

Cuestiones relacionadas