IO모델 (동기vs비동기vs블로킹vs논블로킹)

참조문서

• https://www.slideshare.net/unitimes/sync-asyncblockingnonblockingio
• http://djkeh.github.io/articles/Boost-application-performance-using-asynchronous-IO-kor/

참 많이 보고, 써먹는 용어다. 확실히 정리를 해보자.

일단 IO 작업은 사용자레벨에서 직접 수행할 수 없다. 실제 IO를 수행하는 건 커널에서만 가능하다. 따라서 사용자 프로세스(또는 쓰레드)는 커널에게 IO를 요청해야한다.

1. IO모델

• 블로킹 : 애플리케이션 실행 시 운영체제 대기 큐에 들어가면서 요청에 대한 system call이 완료된 후에 응답을 보낸다.
• 논블로킹 : 애플리케이션 실행 시 운영체제 대기 큐에 들어가지 않고, 실행 여부와 관계없이 바로 응답을 보낸다. 바로 응답하기 힘든 경우, 에러를 반환하는데 정상데이터를 받을 때까지 계속해서 요청을 다시 보낸다.

IO이벤트 통지모델은 논블로킹에서 제기된 문제를 해결하기 위해 고안되었다. IO 이벤트를 통지하는 방법은 크게 동기형 통지모델과 비동기형 통지모델로 나눌 수 있다.

• 동기 : 시스템콜을 기다린다. (notify를 사용자 프로세스가 담당) 시스템의 반환을 기다리는 동안 대기 큐에 머무는 것이 필수는 아니다. (블로킹은 필수로 머물러야함)
• 비동기 : 시스템콜을 기다리지 않는다. (notify를 커널이 담당) 요청에 대해 처리완료 여부에 관련없이 응답하고 다음코드를 돌린다. 이후에 운영체제에서 처리완료여부를 알려주고 응답한다.

2. 동기 블로킹

• 프로그램이 블로킹을 일으키는 시스템 함수를 호출
• 한 작업당 한 번의 사용자-커널사이의 문맥교환 발생
• 정지된 프로그램은 CPU를 사용하지 않고 커널의 응답을 대기
• 프로그램 관점에서 보면 마치 처리로직이 오래걸리는 것 같지만, 사실은 커널의 일을 기다리느라 블록되어 있는 것이다. 이게 개선 포인트

3. 동기 논블로킹

• 동기블로킹의 개선안이지만 비효율적이다. 왜냐하면 위에서 정리했듯이 논블로킹방식은 정상데이터가 올 때 까지 계속 시스템콜을 하며 문맥교환을 한다.
• IO 지연(latency) 초래한다.

4. 비동기 블로킹

• IO는 논블로킹이고 알림(notify)가 블로킹인 방식이다.
• select() 시스템함수 호출이 사용자프로세스를 블로킹한다.
• 비효율적이다.

5. 비동기 논블로킹

• 시스템콜이 즉시 IO개시 여부를 반환한다. 사용자프로세스는 다른일을 할 수 있고(CPU는 다른 업무를 볼 수 있다), IO는 백그라운드에서 처리된다.
• IO 응답이 도착하면 신호나 콜백으로 IO전달을 완료한다.