🐰 멍토의 Blocking vs Non-Blocking, Sync vs Async

[10분 테코톡] 🐰 멍토의 Blocking vs Non-Blocking, Sync vs Async 듣고 정리.

Blocking VS Non-Blocking

다른 작업을 수행하는 주체를 어떻게 다루는지에 관한 관점이다.

Blocking

Blocking : 자신의 작업을 진행하다가 다른 주체의 작업이 시작되면 다른 작업이 끝날 때까지 기다렸다가 자신의 작업을 시작하는 것.

애플리케이션 관점에서, 처음에는 애플리케이션이 자신의 작업을 한다. 그러다가 커널 작업이 시작되면 커널 작업이 진행되는 동안 쉬고 있다. 그러고 커널 작업이 끝나고 나면 다시 애플리케이션의 작업이 진행이 된다.

Non-Blocking

Non-Blocking : 다른 주체의 작업에 관련없이 자신의 작업을 하는 것.

논 블록킹은 다른 주체와 상관없이 자신의 일을 진행한다. 커널이 작없을 시작하는 순간 빠져나와서 다시 자신의 작업을 진행하게 된다.

Synchronous VS Asynchronous

Synchronous

작업을 동시에 수행하거나, 동시에 끝나거나, 끝나는 동시에 시작함을 의미 → 즉 주체들간 작업 수행의 시간을 맞춘다

자신의 작업을 하다가 다른 주체(커널)의 작업을 요청한다. 요청받은 작업은 필요한 작업을 수행하고 다시 결과값을 리턴한다. 결과를 받은 후에야 요청을 보낸 작업은 다시 자신의 작업을 재개한다.

Asynchronous

시작, 종료가 일치하지 않으며 끝나는 동시에 시작을 하지 않음을 의미 → 주체들간 작업 수행의 시간을 맞추지 않는다.

작업을 수행하다 다른 주체(커널)에게 작업을 요청한다. Synchronous와 달리 커널 작업의 결과에 신경쓰지 않고 자신의 작업을 계속 수행한다. 커널작업이 끝나고 결과가 돌아오게 되면 돌아온 결과에 대해서 상황을 처리할 수 도 있고 안할 수 도 있다.

네가지 조합에 대해서

Blocking, Synchronous

Blocking의 관점은 제어권에 있다. 다른 작업이 시작되는 동안 동작하지 않는다.

Sync의 관점은 결과의 처리이다. 다른 작업이 결과를 반환할 때, 결과값을 받고 나서 자신의 작업을 재개한다.

예시)

예시로, 흔히 우리가 사용자에게 입력값을 받는 코드를 들 수 있다.

입력을 요청할때, 제어권이 입력받는 주체(커널)에게 넘어간다. 따라서 scanner.nextLine()이후의 “블록킹 동기”를 출력하는 코드는 입력받는 커널의 작업이 끝날 때 까지 실행되지 않는다.

커널의 입력 작업이 끝나고, 결과를 반환하게 되면, 제어권과 결과를 같이 받아서 이후 작업을 재개하게 된다.

Non-Blocking Sync

Non- Blocking 은 다른 작업의 주체에게 작업을 요청해도 자신의 제어권을 그대로 들고 있고, 계속 자신의 작업을 수행한다.(Non-Block)

헌데 Sync는 결과에 관심이 있는 관점이라고 했다. 따라서, 제어권을 가지고 자신의 코드를 수행하기는 하지만 중간중간에 계속 요청한 작업의 주체에게 작업 완료 여부, 즉 결과(반환)값이 물어본다.

묻고 작업이 아직 완료되지 않았다면 다시 돌아서 자신의 작업을 수행한다. 이같은 과정을 반복한다.

결국 요청한 작업주체의 작업이 끝나 결과를 받을 수 있으면 이제 해당 결과를 받아와 작업을 처리한다(Sync)

예시)

Non-blocking sync는 blocking sync와 거의 큰 차이가 없다.

정확히 말하면, Non-blocking Sync는 Sync를 위해 요청한 작업의 결과를 기다리면서도, 자신의 제어권은 여전히 지녀서 계속 자신의 작업을 진행한다는 차이가 있다. 어떤 예시가 있을까?

→ 게임에서 맵을 넘어가는 코드를 예시로 들 수 있다.

게임에서 맵을 전환 할 때, 맵의 로딩을 기다리면서도 유저에게 맵 데이터를 가지고 올때 진행 완료율을 보여주는 상황을 들 수 있겠다.

Blocking Async

Blocking이기 때문에 자신의 작업에 대한 제어권은 없다. 하지만 Async이기 때문에 요청한 작업의 결과를 기다릴 필요가 없다. 정말 이상한 조합이다.

다시 생각해보면, 요청한 작업의 결과를 기다릴 필요가 없는데도 제어권을 가지지 않아서 자신의 작업은 수행하지 못한다. 동기, 블록킹과 다를 바가 없다. 굳이 이런 상황을 사용할 필요가 있을까?

→ 거의 안쓰이는 조합이라고 보면 된다. 보통 이 조합은, Non-Blocking/Async로 동작하게 하려다가 개발자의 실수로 혹은 기타 등등의 이유로 위와같이 동작하는 경우가 있다고 한다.

의도하고 사용하기 보다는 실수로 사용된다. 예를 들어, 비동기로 다른 작업을 실행했지만, 다른 작업이 내부적으로 (DB 등등) 블록킹으로 수행된다면 이런 상황이 있을 수 있다.

Non-Blocking Async

Non-blocking은 다른 작업이 시작되어도 자신이 하던 작업은 멈추지 않는다. (제어권을 그대로 들고 있기 때문)

따라서 양쪽에서 서로 각자 작업을 처리한다.

그리고, Async는 서로의 결과에 관심이 없다. 다른 작업이 끝난 후 결과를 기다린 후 바로 받아서 처리하는 것이 아니라 자신의 작업이 끝난 후에 처리를 하던지, 혹은 아예 처리를 안할 수 도 있따. ( 혹은 요청하는 작업의 주체에게 요청 결과물을 어떤식으로 처리하라고 콜백함수를 전달할 수도 있다.)

예시)

대표적인 예시로 자바스크립트에서 API 요청을 하고(fetch) 다른 작업을 하다가 요청의 결과값을 받으면, 콜백을 통해서 추가적인 작업을 처리할 때를 들 수 있다.

정리

블록킹/논블록킹은 다른 작업주체에 대한 제어권을 어떻게 처리하는가의 관점. → 제어의 관점

싱크/어싱크는 순서와 결과(처리)의 관점이다.

블록킹과 논블록킹, 동기와 비동기의 네가지 조합은 사실 정확히 뭐가 이렇다 라고 딱 집어서 표현할 수 없다.

아주 국지적인 구역으로 봤을 때는 그 구분이 가능할 수는 있지만 전체적인 코드와 로직의 흐름에서 어떤 조합이다 라고 명확히 구분짓기는 불가능하다.

예를 들어 이 코드를 보자.

2~7줄 전체적으로 보았을 때는 factorial 함수와 위 코드는 동기적으로 동작한다. 왜냐면 line 7, long result = futureTask.get()으로 factorial함수의 작업이 끝나기를 기다렸다가 그 결과물을 받아오고 다시 작업을 재개하기 때문이다.

하지만 그 과정 속에서는 비동기와 논 블록킹 등의 개념을 적용시킬 수 있다. 예를 들어 while문의 조건식에서 futureTask.isDone()으로 factorial함수에게 작업의 완료 여부를 체크하고 있는데 이는 sync/non-blocking조합이라고 볼 수 있다.

하지만 여기에서 조차도 더 깊게 들어가보자. 이 마저도, futureTask.isDone()이라는 함수가 실행될 때 순간적으로 blocking/sync가 일어난다.(isDone()함수를 실행시킴과 동시에 제어권이 넘어가고 본 코드는 실행을 중지, 그리고 isDone()의 반환값인 불린을 받을때까지 Sync하게 동작함)

네가지 개념을 말로 나눌려면 나눌 수 있지만 모든 상황에서 뚜렸하게 나눠지진 않는다.

자바스크립트의 await/async도 이게 과연 동기/비동기라고 할 수 있을까? 전체적으로 봤을 때 코드에서 await을 걸어도 화면은 보이고 이벤트루프는 동작한다. 즉 비동기인 것이다. await의 함수가 쓰이는 국지적인 관점에서는 물론 Sync임은 맞다.

하지만 자바스크립트 전체적인 관점에서는 비동기적으로 작동하는 로직들이 매우많을 것이다.

참고

https://www.youtube.com/watch?v=IdpkfygWIMk