Blocking vs Non-Blocking

시스템의 Blocking과 Non-Blocking을 이해하기 전에 우선 OS의 System Call Interface에 대한 이해가 필요하다.

 

System Call Interface

시스템 콜 인터페이스는 프로세스나 스레드로부터 명령을 받는 인터페이스로써 다음과 같은 역할을 담당한다.

OS Kernel과 System Call Interface 구조

• 운영체제는 커널 모드(Kernel Mode)와 사용자 모드(User Mode)로 나뉘어 구동된다.
• 운영체제에서 프로그램이 구동되는데 있어 파일을 읽어 오거나, 파일을 쓰거나, 혹은 화면에 메시지를 출력하는 등 많은 부분이 커널 모드를 사용한다. 시스템 콜은 이러한 커널 영역의 기능을 사용자 모드가 사용 가능하게, 즉 프로세스가 하드웨어에 직접 접근해서 필요한 기능을 사용할 수 있게 해준다.

 

---

Blocking I/O Model

System Call Interface(시스템 콜 인터페이스)가 하는 중요한 기능 중 하나는 사용자 레벨 요청(어플리케이션)에 대해 blokcing I/O와 nonblocking I/O 중 무엇을 선택하느냐와 관련되어있음.

 

어플리케이션이 blocking 시스템 콜을 호출하는 경우에는 해당 시스템 콜을 호출한 쓰레드의 실행이 중단된다. 일반적으로 I/O 장치에 의해 수행되는 물리적인 행위들은 일반적으로 비동기적(I/O 장치마다 물리적 행위들을 수행하는데 걸리는 시간이 다양하고 예측할 수 없기 때문에)으로 작동한다.

 

1. I/O 작업을 처리하기 위해 User Level에 있던 Application이 시스템 함수를 호출한다(→ system call).
   • 이 때 context-switching 이 발생
2. Kernel Level에서 해당 I/O 작업 진행, I/O가 끝날 때까지 유저 프로세스 대기
   • 끝나기 전에는 함수가 반환되지 않기 때문에 커널이 작업을 완료하기전까지 유저 프로세스는 작업을 중단한 채 대기
   • I/O 작업이 CPU 자원을 거의 쓰지 않기 때문에 Blocking 방법은 CPU 자원 낭비가 심함
   • 애플리케이션 관점에서 보면 아무런 동작도 안하는 것처럼 보이지만 실제로는 커널에서 I/O 작업을 수행하느라 block되어 있음
   • 바로 이 부분이 blocking I/O의 문제점이며 개선 포인트가 됨
   • 이러한 blocking 방식의 비효율성을 극복하고자 만들어 진 것이 non-blocking 방식이다.
3. 작업 완료 후 데이터를 반환하게 되면 그 때가 되어서야 Application단의 스레드에 걸렸던 block이 풀림

 

Non-Blocking I/O Model

---

non-blocking 방식은 I/O 작업을 진행하는 동안 유저 프로세스의 작업을 중단시키지 않음

1. 유저 프로세스가 I/O를 처리하기 위해 커널에 함수를 호출하면(→ system call )
2. 커널에서 함수의 진행 상황과 상관없이 바로 결과를 반환
   • 이 때 반환되는 결과는 반환하는 순간에 가져올 수 있는 데이터에 해당
   • 처음에는 가져올 수 있는 데이터가 없겠지만 시간이 지나면서 가져올 수 있는 데이터가 생겨나게 됨
   • 서버는 클라이언트가 요청한 사이즈에 맞는 데이터를 반환하기 위해 데이터를 축적
3. 클라이언트가 따로 반환되는 값이 원하는 사이즈가 되었는 지 계속해서 확인(→ polling )
   • Non blocking Model은 결국 반환되는 데이터가 준비가 되었는지(원하는 값이 되었는지) 확인하는 과정에서 수많은 클라이언트의 요청이 동시 다발적으로 일어날 경우, CPU에게 적지 않은 부담이 될 수 있는 I/O Model임
4. 데이터의 축적이 끝났을 때, 반환되어 클라이언트에서 요청한 사이즈의 데이터를 받아올 수 있게 됨

---

Asynchronous I/O Model

Event-driven Model로도 불리는 이 모델은 Non-Blocking에서 제기된 문제를 해결하기 위해 고안되었음. Non-Blocking I/O Model에서 처럼 애플리케이션에서 데이터 준비가 되었는지 계속해서 확인하는 것이 아니라,

1. 작업 요청
2. 유저 프로세스는 다른 작업 수행
3. kernel Level에서 데이터가 준비되면 콜백 또는 이벤트를 발생시켜 애플리케이션에 알림(→ notify )
4. 그 때 그에 따른 작업 처리

운영체제 단계의 비동기 API를 통해 이루어지며 I/O작업이 completion이 되면 그에 적합한 Handler를 이용해 처리 

 

---

Synchronous

작업을 요청한 후 해당 작업의 결과가 나올 때까지 기다린 후 처리하는 것으로 I/O 작업에 대한 readiness를 기다린다. 특정 I/O 작업을 하기 위한 준비가 되었는지에 집중하는 것이다. I/O 작업 준비에 대한 이벤트의 발생을 기다렸다가 해당 이벤트가 발생하면 그에 따른 적합한 처리를 한다.