0
우리 응용 프로그램에는 네트워크를 통한 파일 시스템 변경을 포함하여 파일 시스템 변경을 수신하는 하위 시스템이 있습니다. 때로는 네트워크가 스트레스를 받고있을 때 청취 스레드가 멈추는 경우가 있습니다. 필자는 여기서는 잘못된 스레드 동기화로 인한 교착 상태에 대한 논의가 아니라는 점을 강조합니다. 스레드가 CreateFile에 대한 첫 번째 호출에서 또는 파일 시스템 API에 대한 후속 호출에서 걸릴 수 있습니다. 문제는 그러한 스레드로 무엇을 할 것인가입니다.교착 상태 스레드 (교착 상태 아님)로 수행 할 작업은 무엇입니까?
특정 스레드가 일정 기간 동안 비활성 상태이고 종료되는 것으로 판단 할 수 있습니다. 그러나 권위있는 사람들은 죽은 실을 지키는 것이 왜 끝내는 것이 낫다는 것을 이해하지 못한다고해도, 매우 나쁘다고 말합니다. 그렇다면 적어도 파일 핸들과 같이 스레드에 할당 된 일부 리소스를 릴리스 할 수 있다고 생각했습니다.
그래서 파일 핸들을 닫고 죽은 스레드에 의해 할당 된 메모리를 해제하는 스레드 클리너를 만들었습니다. 그러나 곧 나는 더 깨끗한 스레드가 CloseHandle API에 대한 호출에서 스스로 붙어있는 것을 발견하는 것에 놀랐다. 내가 정말로 CloseHandle가 붙지 않을 수 있었기 때문에 나는 정말로 충격을 받았다.
응용 프로그램이 충분히 오래 작동하고 네트워크 또는 그 일부에 여전히 문제가있는 경우 많은 시스템 자원을 보유하는 많은 죽은 스레드로 끝날 수 있으므로 완전히 손실됩니다. !
볼 수 있지만, 아마 당신은 그들이 당신을 말한 오해. 스레드의 상태를 알 수 없을 때 스레드를 강제로 중지하는 것은 좋지 않습니다. 잠긴 것, 잠긴 것, 열린 파일 등은 알 수 없습니다. 그러나 스레드를 _stop_ 제안하지는 않습니다. 당신은 통제 할 수없는 이유로 이미 멈춘 쓰레드를 파괴하는 방법을 묻습니다. –
@james,하지만 실제로 멈춘 스레드가 어떤 상태인지 알 수 없습니다! I/O 요청을 실행하면 내부적으로 내가 알지 못하는 일부 중요한 부분을 입력 할 수 있습니다. 그리고'CloseHandle'이 같은 임계 영역에 접근한다면, 이것은 왜 "Cleaner"쓰레드가 멈추게되었는지를 설명 할 수 있습니다. 당신이 언급 한 모든주의 사항은 제 경우에도 적용됩니다. – Ilia
스레드가 중지되어서는 안되며 스레드가 왜 작동하지 않는지 알지 못한다는 사실. 의심의 여지가 없습니다. 나는 그저 멈춘 스레드를 파괴함으로써 상황을 악화시키지 않을 것이라고 말하고 있습니다. –