블로킹/동기 vs 논블로킹/비동기

기본적인 개념

모든 I/O (File, Network, etc.)는 커널 레벨에서 관리된다.  애플리케이션 레벨에서 직접 I/O를 할 수 없고 모든 I/O는 커널에 System call하여 요청을 하고 그에 따른 응답을 받는 구조로 구성되어 있다는 뜻이다.

이때 애플리케이션과 커널이 소통하는 방식을 정함에 있어 블로킹과 논블로킹, 동기와 비동기로 나뉘게 된다.

 

애플리케이션에서 커널의 응답을 기다리면 블로킹, 기다리지 않고 다른 작업을 진행하면 논블로킹

작업의 순서를 애플리케이션에서 결정하여 순서가 보장되면 동기, 커널에서 결정하고 애플리케이션에 작업의 완료를 통보하면 비동기이다.

 

위에 따르면 총 4개의 경우의 수가 나오며 블로킹-비동기, 논블로킹-동기에 대한 예시(polling)가 있긴 하지만 블로킹/동기, 논블로킹/비동기 2가지 경우만 생각해도 무방할 것이라 생각한다.

 

블로킹/동기

핵심 패러다임

커널이 아닌 애플리케이션 레벨에서 모든 흐름을 관장

 

장점

개발자가 모든 것을 통제하므로 논리적 오류를 제외한다면 결과에 대한 무결성을 보장할 수 있음

요청을 처리하려면 단순히 스레드를 생성해서 해당 요청을 처리하면 되므로 내부 구조가 간단

 

단점

커널에서의 I/O 작업은 CPU를 거의 사용하지 않고 I/O 컨트롤러를 이용하므로 이 작업을 기다리는 동안 애플리케이션의 CPU는 idle 상태가 되고 요청마다 처리하는 스레드를 생성해야 하므로 이를 관리하는 메모리 등에서 리소스 손해를 볼 수 있음

커널에서 대부분의 작업은 비동기적으로 이뤄지므로 서로 다른 패러다임으로 인한 손해가 발생할 수 있음

 

논블로킹/비동기

패러다임

흐름 관리의 주체가 개발자가 아닌 커널과 이벤트를 관리하는 메인스레드로 넘어감

 

장점

CPU와 메모리같은 리소스의 사용량을 극대화하여 낭비를 최소화할 수 있다.

성능이 더 좋아질 "수도" 있다. 서로간의 우위가 있는 것이 아닌 시스템 디자인의 차이이므로 애플리케이션이 제공하는 서비스에 따라 달라진다.

기존 시스템이 I/O Intensive한 서비스였고 I/O 과정에서 병목이 생겼다면 극적으로 성능이 좋아질 수도 있고 반대로 CPU Intensive한 구조였다면 메인스레드가 CPU 작업에 의해 block되게 되므로 성능이 극적으로 안 좋아질 수도 있다.

 

단점

I/O 이벤트를 처리하는 메인 스레드와 실제로 작업을 처리하는 구조로 나뉘어야 하므로 내부 구조가 더 복잡해진다.

흐름을 메인스레드가 관리하지만 순서를 보장해주는 것은 아니므로 순서에 대해서는 개발자가 신경써야한다.

 

레퍼런스

https://blog.naver.com/n_cloudplatform/222189669084

[네이버클라우드 기술&경험] IO Multiplexing (IO 멀티플렉싱) 기본 개념부터 심화까지 -1부-

https://en.wikipedia.org/wiki/Asynchronous_I/O

Asynchronous I/O - Wikipedia