Tengo una utilidad que he escrito en C # para comunicarme con nuestro dispositivo USB. Usamos el controlador HID genérico y envolvemos un identificador para el dispositivo en unFileStream objeto. Yo leo / escribo datos usando suBeginRead yBeginWrite métodos, no porque necesite E / S asíncrona, sino simplemente para que pueda agotar el tiempo de espera en caso de que el dispositivo entre en un estado no transmisible (intencionalmente o no). Toda lectura / escritura se realiza en mi propio hilo dedicado de IO.

Me preocupa que no estoy haciendo las cosas bien, porque he visto algunos casos de lo que sospecho que es un punto muerto en el hilo. Aquí está una versión reducida de mi relevanteRead Método (que parece funcionar bien).

if (_readResult == null)
{
  _readResult = _deviceStream.BeginRead(_readBuffer, 0, _readBuffer.Length, null, null);
}

if (_readResult.AsyncWaitHandle.WaitOne(IOTimeout, true))
{
  int bytesRead = _deviceStream.EndRead(_readResult);
  _readResult.AsyncWaitHandle.Close();
  _readResult= null;
  // … Copy bytes to another buffer
}
else
{
  // … Timeout, so retry again in a bit
}

Mi pregunta principal es cómo detener adecuadamente un inacabadoBeginRead oBeginWrite llame si necesito terminar mi hilo IO y mi dispositivo ya no se está comunicando. No puedo simplemente llamarEndRead porque se sentará allí y bloqueará para siempre. Es seguro llamarFilestream.Close ¿Mientras que las operaciones de lectura / escritura están pendientes?

También tengo que preguntar, ¿es seguro tener operaciones de lectura y escritura pendientes ejecutándose simultáneamente? Por ejemplo, si mi método de lectura se agota, ¿puedo seguir adelante e intentar escribir algo?

Es difícil reproducir mi problema actual de interbloqueo, pero la parte realmente extraña es que parece comenzar cuando el hilo IO se "atasca" en mi método de lectura. No estoy seguro de cómo sucedería eso a menos que mi código no esté funcionando como creo que lo está.