동기, 비동기 그리고 Blocking, Non-Blocking 2편 | 조합해볼까?

동기, 비동기 그리고 Blocking, Non-Blocking 1편 | 비교해볼까?

 

목차

1. 이전 편에 이어서
2. 동기, 비동기, Blocking, Non-Blocking 조합
   1. 동기 + Blocking
   2. 동기 + Non-Blocking
   3. 비동기 + Non-Blocking
   4. 비동기 + Blocking
3. 또 다음편?
4. 참고

 

---

 

이전 편에 이어서

이전 편에서 동기, 비동기, Blocking, Non-Blocking에 대해서 살펴보았습니다. 동기와 비동기는 작업 처리 흐름에 관련된 개념이고, Blocking과 Non-Blocking은 작업 중 제어권 반환 여부에 관련된 개념입니다. 그래서 각 개념 묶음이 독립적이라서 조합을 만들어 볼 수 있습니다. 이제부터 각 조합에 대해 살펴보겠습니다.

(표) 동기, 비동기 그리고 Blocking, Non-Blocking 조합

 

 

동기, 비동기, Blocking, Non-Blocking 조합

각 조합을 살펴보기 전에 이해를 돕기 위해 2가지를 이야기하고자 합니다. 첫 번째는 앞으로 나올 예시는 모두 A 작업이 진행 중에 B 작업을 호출한 상황입니다. 작업 간의 처리 흐름이 동기인지 비동기인지 또는 A 작업이 Blocking인지 와 같은 조건은 각 조합에서 자세히 이야기할 것입니다. 두 번째는 동기, 비동기, Blocking, Non-Blocking의 의미를 더 직관적인 말로 바꿉니다. 동기, 비동기는 '작업 처리 흐름'에서 '작업의 완료 여부를 누가 확인하는가?'로 바꾸고, Blocking, Non-Blocking 은 '제어권 반환 여부'에서 '작업 완료까지 대기하는가'입니다. 혹시 뭔가 이상한 부분이 있는데 눈치채셨나요? 1편에서 동기, 비동기 이야기할 때 '작업 완료까지 대기하는지'로 설명했습니다. 그런데 더 직관적인 말로 바꾼다면서 Blocking, Non-Blocking 이야기할 때 '작업 완료까지 대기하는지'로 바꿨습니다. '작업 완료까지 대기하는가'를 알아보면 동기, 비동기, Blocking, Non-Blocking의 특징이지 구분 기준이 아닙니다. 이런 혼란을 방지하고자 직관적인 말로 바꿨습니다.

 

동기 + Blocking

동기 + Blocking

B 작업의 완료 여부는 호출한 함수인 A 작업에서 확인합니다. 그리고 A 작업은 Blocking 특징을 가졌으므로 순차적으로 하위 작업을 수행합니다. 즉, 코드가 한 줄이 완료되어야 다음 줄로 넘어간다고 생각하시면 됩니다. 구체적인 흐름을 살펴보겠습니다. A 작업은 시작하고 B 작업을 호출한 후 완료될 때까지 대기하게 됩니다. B 작업이 완료되면 A 작업의 남은 부분을 진행하게 됩니다. 그럼, A 작업은 B 작업의 완료 여부를 언제 확인할까요? B 작업이 완료와 함께 A 작업이 제어권을 갖게 되면서 B 작업이 완료되었다고 판단할 수밖에 없습니다. 왜냐하면 동기, Blocking인 상황이니까요.

 

동기 + Non-Blocking

동기 + Non-Blocking

이번에도 B 작업의 완료 여부를 호출한 함수인 A 작업에서 확인합니다. 그리고 A 작업은 Non-Blocking 특징을 가졌으므로 순차적으로 하위 작업을 실행하지만, 각 작업의 완료를 대기하지 않고 다음 하위 작업을 실행합니다. 간단하게 정리하면 A 작업은 B 작업을 호출한 후 완료되었는지 계속 확인합니다. 동기적이기 때문에 A 작업은 B 작업을 호출한 이후의 작업을 진행할 수 없습니다. 그럼 자연스럽게 A 작업은 B 작업이 완료될 때까지 계속 확인하게 됩니다. 이러한 상황은 언제 일어나는 걸까요? 쉽게 경험할 수 있는 예시로는 플래시 게임에서 '로딩바'가 있습니다. 해당 화면에서 로딩이 끝날 때까지 다음 화면으로 넘어갈 수도 없고 클릭이나 키보드 입력에 대한 상호작용을 진행하지 않습니다.

 

 

비동기 + Non-Blocking

비동기 + Non-Blocking

비동기로 넘어왔습니다. B 작업의 완료 여부는 더 이상 A 작업이 하지 않습니다. 누군가 B 작업이 완료되었다고 A 작업에게 알려줘야 합니다. 이 누군가는 B 작업이 될 수도 있고 다른 방법(이벤트, 콜백 등)이 될 수도 있으니 설계한 사람에 따라 정해지게 됩니다. 그리고 A 작업은 Non-Blocking 특징을 가졌으므로 하위 작업들이 완료와 무관하게 진행됩니다. 결국 A 작업의 흐름은 B 작업을 포함한 하위 작업은 완료 여부와 무관하게 다음 하위 작업으로 진행하는 것입니다. 그리고 B 작업과 같이 완료 여부가 A 작업에게 알려줘야 하는 경우 설계자가 정한 방법을 통해 알려주게 됩니다.

 

비동기 + Blocking

비동기 + Blocking

마지막 조합입니다. 여기도 A 작업은 B 작업의 완료 여부를 확인하지 않습니다. 그리고 A 작업의 하위 작업은 완료될 때까지 대기하면서 순차적으로 진행됩니다. 구체적인 흐름을 살펴보겠습니다. A 작업이 시작되고 하위 작업을 순차적으로 실행합니다. 각 하위 작업은 이전 하위 작업이 완료될 때까지 대기한 후 실행됩니다. B 작업도 마찬가지로 완료될 때까지 A 작업은 대기 된 상태입니다. B 작업이 완료되면 이후 하위 작업도 동일하게 진행됩니다. 뭔가 동기 + Blocking일 때와 동일한 흐름처럼 느껴집니다. 단지 차이점은 B 작업의 완료를 A 작업이 확인하지 않고 설계자가 만든 방법을 통해 알게 됩니다. 그런데 B 작업의 완료될 때 A 작업은 제어권을 얻기 때문에 B 작업 완료 여부를 자연스럽게 알 수 있습니다. 그럼, 왜 자연스럽게 얻는 제어권이 아닌 다른 방법을 통해 확인할까요? 오히려 B 작업 완료 여부를 확인하기 위해 다른 방법을 설계하고 구현해야 해서 불필요한 작업이 생기는 느낌입니다. 그래서 실제로 이러한 패턴이나 설계는 잘 하지 않습니다.

 

 

또 다음편?

각 조합에 대해서 살펴보았습니다. 직관적으로 의미를 바꿔 설명하다 보니 1편에 비해 설명하기 수월했다고 느껴졌습니다. 그리고 어떻게 마무리할지 고민했습니다. 이론적인 내용은 충분하니 실제 언어를 활용해서 살펴보면 좋겠다는 생각이 들었습니다. 그래서 다음 편에서 실제 언어를 가지고 동기, 비동기, Blocking, Non-Blocking을 살펴보겠습니다.

 

동기, 비동기 그리고 Blocking, Non-Blocking 3편 | 작성해볼까?

 

 

 

참고

• 👩‍💻 완벽히 이해하는 동기/비동기 & 블로킹/논블로킹
• 블럭,논블럭,동기,비동기 이야기
• [운영체제] Blocking, Non-blocking & Synchronous, Asynchronous