Blocking vs Non-Blocking

요청 시 제어권을 커널로 넘겨주니?

Yes! → Blocking (제어권이 넘어가서 요청에 대한 응답이 있기 전까지 대기(blocking) 상태)

• Application이 kernel로 작업 요청을 할 때, kernel에서는 요청에 대한 로직을 실행. 이때, Aplication은 요청에 대한 응답을 받을 때 까지 대기 ⇒ kernel에 요청 보내고, 응답 받기 전까지 아무것도 못함 ⇒ 작업이 많은 경우 작업 처리 속도가 느려질 수 있음
  

No! → Non-Blocking (제어권을 그대로 갖고 있어서 block 되지 않고 다음 로직을 수행)

• Application에서 요청 이후 바로 제어권을 받아 다음 로직을 실행 ⇒ kernel에 요청 보내 놓은 뒤로 바로 다음 로직 실행 ⇒ 한 번에 여러 개의 작업을 동시에 처리할 수 있기 때문에 처리 속도가 빠르고, 작업이 많은 경우 효율적임.
  

Sync vs Async (동기 vs 비동기)

요청한 작업의 완료 여부를 신경 쓰니?

Yes! → Sync (커널의 상황과 동기화 되어있어야 해!)

• Application에서 kernel의 작업 완료 여부를 계속 신경 씀
• 리턴값을 받아서 바로 처리

No! → Async (커널의 상황이 어떻든 상관 없어)

• Application에서 kernel의 작업 완료 여부를 신경 쓰지 않음
• 리턴 값(DataMovement)을 받으면 어떻게 할지 콜백 함수를 미리 정의해 둬서, 콜백 함수를 받아서 완료된 것을 확인, 나중에 처리

Blocking/Non-Blocking, 동기/비동기

	요청 보낸 후 Application 동작	비고
Sync Blocking	작업 완료가 되기 전까지 아무 동작 하지 않음	-
Sync Non-Blocking	작업 완료 여부 계속 확인하면서 이후 로직 수행	-
Async Blocking	콜백 함수 받기 전까지 아무 동작 하지 않음	잘 사용하지 않음 (Sync Blocking과 성능 비슷, 콜백만 한번 더 보내주므로 거의 사용 x)
Async Non-Blocking	로직 수행하면서 콜백 함수 받으면 반영	-

그림 출처: https://annajin.tistory.com/101

Reference

블로킹 Vs. 논블로킹, 동기 Vs. 비동기

[10분 테코톡] 🐰 멍토의 Blocking vs Non-Blocking, Sync vs Async