Eu tenho um utilitário que eu escrevi em C # para se comunicar e voltar com o nosso dispositivo USB. Usamos o driver HID genérico e colocamos uma alça no dispositivo em umFileStream objeto. Eu leio / escrevo dados usando seusBeginRead eBeginWrite métodos, não porque eu preciso de E / S assíncrona, mas simplesmente para que eu possa tempo limite no caso do dispositivo entra em um estado não-comunicável (intencionalmente ou não). Toda a leitura / escrita é feita no meu próprio thread IO dedicado.

Estou preocupado que eu não esteja fazendo as coisas corretamente, porque eu vi alguns casos do que eu suspeito ser um impasse de thread. Aqui está uma versão simplificada do meu relevanteRead método (que parece funcionar bem).

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
}

Minha principal questão é como parar corretamente um inacabadoBeginRead ouBeginWrite ligue se eu precisar terminar meu thread IO e meu dispositivo não estiver mais se comunicando. Eu não posso simplesmente ligarEndRead porque vai ficar lá e bloquear para sempre. É seguro ligarFilestream.Close enquanto as operações de leitura / gravação estão pendentes?

Eu também tenho que perguntar, é seguro ter pendente ler e escrever operações em execução simultaneamente? Por exemplo, se meu método de leitura expirar, posso continuar e tentar escrever algo?

É difícil reproduzir meu problema de deadlock atual, mas a parte realmente estranha é que ele parece iniciar quando o thread de IO fica "preso" no meu método de leitura. Não tenho certeza de como isso aconteceria, a menos que meu código não esteja funcionando do jeito que eu acho que é.