Asynchronous vs synchronous execution, what does it really mean? : sync와 async 차이에 대한 설명

궁금해서 이해한 내용을 기술합니다. "Boost application performance using asynchronous I/O" 문서에서 이해한 것은 sync는 kernel이 user에게 공지할 수 없는경우, async는 kernel이 user에게 공지할 수 있는 경우 사용한 용어로 봤습니다.

sync non-block i/o : kernel 이 공지할 수 없으니 자료를 읽을려면 다시 진입해야 합니다. 그래서 sync 입니다. async block i/o : kernel이 공지를 할수 있지만, 자료가 준비되기 전까지는 block되는 것을 설명한 것 같습니다(이부분은 제가 봐도 async 개념이 어울리지 않습니다).

제가 추천하는 부분은 아래 문서의 마지막 장의 요약 내용입니다. (http://courses.cs.washington.edu/courses/cse333/12su/lectures/lec21.pdf)

한 동안 잊고 지내다 갑자가 생각나 다시 한번 정리하는 시간을 가졌다. 한참의 시간이 지난 후에 다시 한번 살펴보니 지난 번보다는 좀 더 명확해 졌다. 그런 의미에서 글로 정리해 본다.

이 내용은 위 댓글에도 있듯이 asynchronous vs non-blocking 문서와 NEXT 학생 중 한명이 작성한 Sync async-blocking-nonblocking-io 문서를 근간으로 한다.

먼저 이 내용에 대해 다루기 전에 이 용어들이 Context에 따라 다른 개념으로 사용되고 있기 때문에 그 부분을 먼저 명확히 해야 한다.

method api call 또는 thread 개념

• synchronous와 blocking은 같은 개념이다.
• synchronous(또는 blocking)는 api call을 보낸 후 응답을 받을 때까지 대기 상태에 있다 응답을 받은 후 종료, asynchronous는 api call을 보낸 후 실행 여부와 관계없이 바로 응답을 받는다.

애플리케이션에서 운영체제로의 system call

• 이 내용은 Sync async-blocking-nonblocking-io 문서 기반으로 정리했다.

blocking vs non-blocking

• 애플리케이션 실행 시 운영체제 대기 큐에 들어가면서 요청에 대한 system call이 완료된 후에 응답을 보낼 경우 blocking
• 애플리케이션 실행 시 운영체제 대기 큐에 들어가지 않고, 실행 여부와 관계없이 바로 응답을 보낼 경우 non-blocking

non-blocking vs asynchronous

• system call이 반환될 때 실행된 결과와 함께 반환될 경우 non-blocking
• system call이 반횐될 때 실행된 결과와 함께 반환되지 않는 경우 asynchronous
• asynchronous는 요청에 대해 처리 완료의 여부와 관계없이 바로 응답한다. 이후 운영체제에서 응답할 준비가 완료되는 시점(예를 들어 네트워크로부터 데이터를 받는 요청의 경우 데이터가 준비되는 경우)에 응답한다.
• non-blocking은 요청에 대해 바로 응답할 수 있는 경우 응답을 하고, 바로 응답하기 힘든 경우 에러를 반환한다. 에러를 받을 경우 데이터를 정상적으로 받을 때까지 계속해서 요청을 다시 보낸다. 우리들이 흔히 이야기하는 polling 방식의 구조를 생각하면 된다. 이와 관련해 Blocking / Non-Blocking 글의 Non-blocking I/O Model 그림을 보면 좀 더 명확하게 이해할 수 있다.

• Blocking / Non-Blocking 글을 보면 asynchronous에 대해 다음과 같이 설명하고 있다.

  이와 반대로 비동기형 통지모델은 일단 커널에게 I/O작업을 맡기면 커널의 작업 진행사항에 대해서 프로세스가 인지할 필요가 없는 상황을 말한다. 유저의 프로세스가 I/O 동기화를 신경쓸 필요가 없기에 비동기형이라고 부를 수 있다. 따라서 비동기형 통지모델에서 Notify의 적극적인 주체는 커널이 되며, 유저 프로세스는 수동적인 입장에서 자신이 할일을 하다가 통지가 오면 그때 I/O 처리를 하게 된다.

synchronous vs asynchronous

• system call의 완료를 기다리면 synchronous
• system call의 완료를 기다리지 않으면 asynchronous

synchronous vs blocking

• 시스템의 반환을 기다리는 동안 대기 큐에 머무는 것이 필수가 아니면 synchronous
• 시스템의 반환을 기다리는 동안 대기 큐에 머무는 것이 필수이면 blocking

Blocking / Non-Blocking 글을 보면 Blocking vs Non-Blocking I/O Model에 대해 설명하고 있으며 synchronous vs asynchronous는 Non-Blocking I/O Model에서의 통지 모델로 설명하고 있다. 통지 모델 관련해 인용해 보면 다음과 같다.

이벤트 통지 모델은 Non-Blocking에서 제기된 문제를 해결하기 위해서 고안되었다. I/O처리를 할 수 있는 소켓(혹은 파일 디스크립터)을 가려내서 가르쳐준다면, 다시말해 입력 버퍼에 데이터가 수신되어서 데이터의 수신이 필요하거나, 출력버퍼가 비어서 데이터의 전송이 가능한 상황을 알려준다면, 위에서 이야기한 구조보다 더 단순하고 효과적으로 다중 I/O모델을 처리할 수 있을 것이다. I/O 이벤트를 통지하는 방법은 크게 동기형 통지모델과 비동기형 통지모델로 나눌 수 있다.

Blocking / Non-Blocking 글도 이 개념들을 이해하는데 많은 도움이 된다.

위와 같이 정리할 수 있다. 단, 위 내용들을 이해하려면 애플리케이션 실행과 운영체제에 대한 지식과 I/O에 대한 지식이 필요하다. 이와 관련한 지식이 없는 상태에서 이해하려 하는 경우 이해하는데 어려움이 있다.