[OS] Blocking / Non-Blocking & Synchronous / ASynchronous

Intro

---

• 개발을 하다보면, 동기 / 비동기, Blocking & Non-Blocking 라는 용어는 한 번쯤 들어봤을 것이다.
• 그러나, 동기 / 비동기 & Blocking / Non-Blocking 각각의 내용을 제대로 명확하게 설명하기란 쉽지가 않다.
• 그래서 하나씩 뜯어 보면서, 어떤 목적으로 사용하는지에 대해 정리하고자 한다.

Blocking I/O

---

• Application단에서는 I / O 작업을 직접 실행시킬 수 없다. 그래서 System_call로 Kernel을 통해 작업을 수행할 수 있다.
  • system_call을 하게 되면 context-swtiching이 발생하면서 작업이 수행된다.
• 여기서 Blocking I / O을 통해 작업을 수행할 경우에는, 실행한 함수가 반환될 때까지 "대기"하고 있는 상태가 된다.
• 작업이 완료되면, 수행한 쓰레드는 Block이 풀리면서, 다른 작업을 수행할 수 있게 된다.
• 즉, Blocking I / O 작업의 경우 호출한 작업을 처리하는 동안 다른 작업을 할 수 없는데, 요청한 작업의 시간이 길어지게 되면 뒤이어 오는 작업들은 무한정 대기할 수 밖에 없고 CPU 자원 낭비를 초래하게 된다.

Non-Blocking

---

• 반대로, Non-Blocking I / O 모델의 경우, 작업 요청 완료 여부와 상관없이 바로 반환하여 제어권을 다시 Application에 넘겨주게 된다.
• Blocking I / O의 경우 단일 쓰레드가 하나의 작업을 수행하면, 작업이 끝나고 결과를 반환할 때까지 다른 일을 수행할 수 없게 되는데 이렇게 되면 CPU 자원 낭비가 발생하게 된다.
• Non-Blocking I / O는 작업 완료의 상관없이 바로 제어권을 반환하기 때문에, 보다 효율적으로 CPU 자원을 활용할 수 있게 되는 것이다.
• 그리고 여기서 Synchronous & Asynchronous 각 방법에 따라 작업 수행 완료를 확인하게 되는데, polling 작업이 수행해 수시로 작업 완료 여부를 확인하는 방법과 Callback 함수 or 이벤트를 통해 함수 종료 시점을 전달하는 두 가지 방법으로 나뉘게 된다.

Synchronous & Non-Blocking

---

• Synchronous은 작업을 수행 완료 여부에 관심을 가지며, 위 그림 처럼 계속해서 완료 여부를 수시로 체크하게 된다.
• Synchronous & Non-Blocking I / O 모델은 Blocking I / O모델의 CPU의 자원 낭비를 개선할 수는 있지만, 수시로 작업 완료 여부를 확인하는 점에서 수많은 클라이언트 요청이 동시에 이루어질 경우 CPU에 부담이 갈 수 있는 I / O 모델이다.

Asynchronous & Non-Blocking

---

• 반면에, Asynchronous & Non-Blocking I / O 모델은 callback 함수 or 이벤트 호출을 통해 작업 완료 여부를 전달하기 때문에, CPU 자원을 효율적으로 처리하면서 synchronous와 달리 작업 완료의 여부를 지속적으로 확인하지 않기 때문에 CPU에 무리가 덜한 모델이다.
• 즉, Asynchronous & Non-Blocking은 작업 수행 요청 이후 제어권을 바로 반환 받은 이후 다른 작업을 계속해서 수행한 다음 callback 함수 or 이벤트 요청이 오면 요청한 작업의 완료 결과를 반환 받아 이후 작업을 수행하게 되는 것이다.

Asynchronous & Blocking

---

• Asynchronous & Non-Blocking, synchronous & Non-Blocking의 차이점까지는 어느정도 끄덕이면서, 납득(?)이 되는데 Asynchronous & Blocking I / O 모델은 이게 왜 있지? 라는 의문이 들게 된다.
• 위 내용에 기반하면 Asynchronous & Blocking I / O은 호출되는 작업의 제어권이 바로 반환되지 않고, 작업 완료 여부에 관심을 가지지 않는 것이다.
• 단일 쓰레드가 입장에서 Blocking으로 인해 제어권이 작업이 완료되기 전까지 반한되지 않기 때문에, 다른 작업을 수행하지 못하는 점에서는 synchronous & Blocking I / O 모델과 큰 차이가 없어 보인다.
• 실제로 Asynchronous & Blocking I / O 모델은 이점이 없어 거의 사용 되지 않는다고 한다.
• 그러나, Asynchronous & Non-Blocking I / O 모델을 추구하다가 의도와 다르게 Asynchronous & Blocking I / O 모델로 바뀌는 경우가 있다고 하는데, 그게 바로 Node.js & MySQL 조합이라고 한다.
  • Node.js 쪽에서 callback을 진행하면서 Asynchronous을 진행한다고 해도 DB 작업 호출 시 MySQL에서 제공하는 드라이버를 호출 하면서 드라이버로 인해 Blocking 방식이 된다고 한다.

Blocking & Non-Blocking

---

• Blocking & Non-Blocking의 주 관심사는 작업의 "제어권 반환"에 있다.
• Blocking의 경우 작업 완료 여부를 기다리면서 제어권을 반환한다면, Non-Blocking은 작업 완료 여부의 상관없이 바로 제어권을 반환해서 다른 작업을 수행할 수 있게 된다.
• Non-Blocking이 CPU 자원 측면에서, 효율적으로 보일 수 있으나 무조건적으로 Non-Blocking이 좋다고 볼 수는 없다.
• 가령, Non-Blocking은 요청한 작업의 완료를 기다리지 않고, 바로 다른 작업을 수행할 수 있기 때문에 동기화 이슈에 대해 항상 고려해봐야 한다.
• 반면에, Blocking은 동기화를 위한 방법을 사용될 수 있게 되는 것이다.

Synchronous & Asynchronous

---

• Synchronous & Asynchronous 주 관심사는 "작업 완료 여부에 관심"을 가지고 있느냐이다.
• Synchronous은 Polling 방식을 통해 지속적으로 요청한 작업의 완료 여부를 확인을 한다면, Asynchronous는 callback 함수나 이벤트 호출을 통해 지속적으로 작업 완료 여부를 확인하지 않고 다른 작업을 수행할 수 있게 된다.