SocketAsyncEventArgs 의 EventHandler와 threadPool

혹시 저와같이 디버깅도 안되는 수많은 작업쓰레드의 정체에 대하여 궁금중을 가지고 계신분들에게 제 나름대로 찾은 답을 공유해봅니다. C#의 threadPool에는 2가지 thread가 있는데 하나는 일반적인 worker thread이고 또하나는 I/O작업이 완료되었을때의 작업을 담당하는 (I/O) completion port thread가 입니다. 소켓통신은 CPU가 아니라 I/O단에서 이루어지는 작업이기 때문에 SocketAsyncEventArgs의 Complete eventHandler는 completion port thread가 담당하여 invoke합니다 (Pending == true일때만 입니다). (해당 쓰레드가 디버깅이 안될때가 많은 이유는 complete이벤트를 다 끝내고 해당 쓰레드풀과 관련된 내부 로직을 실행하고있거나 waiting 상태이기 때문인것 같습니다.) 따라서 complete 이벤트에 무거운 작업을 연결해준다면 소켓통신이 완료될때마다 해당 I/O complete를 담당할 쓰레드가 부족하기 때문에 지속적으로 새로운 completion port thread가 생성되고 이는 리소스 낭비로 이어집니다. 제 실습 프로젝트의 경우에서는 completion port thread가 packet 역직렬화와 log를 찍는 작업을 포함하는 일련의 작업을 수행하고 그렇게 생성된 packet을 packet Handler담당 쓰레드에게 던져주고 있었기 때문에 client수가 많아질수록 스레드수가 급격하게 많아지는등 여러가지 문제가 발생했는데 위의 작업을 lambda로 묶어 통채로 packet handler에게 던져주기만을 하게 수정했더니 쓰레드 생성수가 눈에띄게 줄었고 어느정도 시간이 지나면 전체 쓰레드수도 어느정도 일정하게 유지됨을 확인했습니다. 공부하는데 가장 도움이 많이 된 자료는 Jeffrey Richter의 CLR via C#, 그리고 같은 저자의 C++ 관련 책입니다. 짧은 지식으로 찾은 정보이기 때문에 정확하지 않을수 있습니다. 잘못된 정보가 있다면 알려주세요. 감사합니다.

Custom db?

답변 감사합니다

Listener 관련 질문

답변 감사합니다 혹시라도 운이 없어서 하나의 물고기에 2개 이상의 낚시대가 반응 (args.completed 이벤트 발생)할수도 있다고 생각했는데 그러한 일이 발생할수도 있나요?

send와 lock

답변 감사합니다. 그렇다면 send를 하는 거의 모든 부분에 lock이 결려있는 상태인데 성능을 고려했을때 lock을 거는 부분은 적을수록 적절하다고 알고있습니다. 여기서 lock을 잡는 부분을 줄이거나 좀더 최적화를 하려는 시도가 의미가 있나요 아니면 이러한 구조는 이미 오랜시간 최적화가 끝난 결과물이므로 이대로 받아들이는것이 좋나요?

Json 파일 추가시 에러

저도 동일한 오류를 경험했습니다. 제 경우에는 유니티에서 Edit -> Preferences -> External Tools -> Regenerate project files을 다시 하니 해결되었습니다. 그리고 유니티를 실행하기 전에 비주얼스튜디오를 먼저 실행하고 그 다음 유니티를 실행하였습니다.