Sync,Async,Blocking, Non-Blocking

sync,async는 처리되는 방식의 특징 (I/O 모델) blocking,non-blocking I/O 호출한 입장에서의 특징 (이벤트 통지 모델)

• async

  • 작업을 실행하고 요청 스레드는 다른 작업을 실행
  • 해당 스레드가 죽든지 말든지 don't care
  • 실행 결과를 신경쓰지 않음

• sync

  • 이벤트를 자신이 직접 처리(확인의 주체가 유저 프로세스이며, 다 될때까지 기다리거나 스스로 확인)
  • 메소드,작업등을 실행하고 해당 메소드의 결과를 얻어올 때 까지 기다리는 방식

• block

  • 완료까지 대기(리턴되기 전까지 멈춤)

• non-block

  • 미완료라도 즉시 리턴

I/O를 처리할때 어떻게 조합을 하냐에 따라서 4가지 모델로 구분할 수 있다. 4가지 모델을 현실세계에 비유해서 정리하면 아래와 같다.

Synchronous Blocking

1. 카페에 가서 커피를 주문
2. 원두가 있으면 커피를 내려준다.
3. 원두가 없는경우 "잠깐만요 여기서 기다려주세요" 하고 사러간다.
4. 커피가 만들어졌는지 안만들었는지 내가 계속 확인한다.

Synchronous Non-Blocking

1. 카페에 가서 커피를 주문
2. 원두가 있으면 커피를 내려준다.
3. 원두가 없는경우 "원두사서 오는동안 잠깐 다른일 하세요"하고 원두를사러간다.
4. 커피가 만들어졌는지 안만들었는지 내가 계속 확인한다.

Asynchronous Blocking

1. 카페에 가서 커피를 주문
2. 원두가 있으면 커피를 내려준다.
3. 원두가 없는경우 "잠깐만요 여기서 기다려주세요" 하고 사러간다.
4. 벨이 울리면 받으러 간다.

Asynchronous Non-Blocking

1. 카페에 가서 커피를 주문
2. 원두가 있으면 커피를 내려준다.
3. 원두가 없는경우 "원두사서 오는동안 잠깐 다른일 하세요" 하고 원두를사러간다.
4. 벨이 울리면 받으러 간다.

---

I/O 모델

• I/O 작업은 사용자 모드에서 직접 수행할 수 없다. 실제 I/O 작업은 커널에게 system call을 통해서 요청한다.
• 사용자 레벨에서 system call을 보내고 응답 받는 방법에 따라서 blocking model과 non-blocking모델로 구분할 수 있다.

Blocking vs Non-Blocking

호출한 입장에서의 특징

• 다른 메서드를 실행하고 종료를 기다림 (Block)
• 다른 메서드를 실행하고 종료를 기다리지 않음 (Non-block)

한줄로 설명하면 I/O 작업 시스템 콜을 하고 스레드가 ready qeueue에 들어가서 작업이 완료될때까지 가디라면 blocking이다. 반면, ready queue에 들어가지 않고 바로 응답을 보내면 non-blocking모델이다.

Blocking IO

• I/O작업이 필요한 API Call을할때, 응답을 즉시 받을수 없고 딜레이가 발생한다.
• 하드 디스크에 파일을 저장하는경우 SATA 케이블을 통해서 전송
• 네트워크로 부터 오는 데이터는 네트워크 테이블을 따라서 전송되고 라우터를 통과하고 네트워크 인터페이스 카드를 통해서 수신하게 된다.
• I/O작업이 필요한 API Call을하면 running 상태의 스레드를 block 상태로 만든다.(요청한 데이터가 처리되어서 return될때까지)
• 리눅스 운영체제를 예로들면 해당 스레드는 sleep 상태가 되고, cpu에 접근할 수 없는 상태가 된다.
• 처리가 완료되면 해당 스레드는 Runnable 상태가 된다.
• 해당 스레드는 ready queue에서 대기하다가 스케줄러에 의해서 cpu 제어권을 가져간다.

스레드의 상태는 운영체제에 따라 다르다.

• 리눅스 : running ,not-running
• JVM : new,runnable,blocked,waiting,timed_waiting,terminated

CPU-bound blocking

• 3D 연산과 같이 CPU에 집중되는 작업을 처리하는 스레드는 blocking 당한다.
• CPU 프로세서가 오랜시간 작업을 처리하기 때문에 blocking

IO-bound blocking

• IO자원으로 부터 데이터를 기다리기 위해서 스레드가 blocking 당하는 상황이다.
• IO 요청을하고 커널은 지금당장 리턴할 데이터가 없다고 알려주면서 해당 스레드는 sleep하게 된다.
• CPU는 다른 스레드를 처리하고 있는다.

Non-Blocking IO

• Blocking IO는 리턴할 데이터가 있을때 까지계속 기다린다고 했다.

• Non-Blocking API를 호출하면 어떻게 될까?

• 호출과 동시에 즉시 리턴하고 스레드는 block당하지 않는다.

• 스레드는 즉시 다른 코드를 처리한다(I/O Call 하단에 적은 코드)

• IO장치로부터 데이터가 오면, 호출측에서는 데이터가 준비되었다는것을 알게된다.

• 일반적으로 callback 함수가 응답받은 데이터를 처리한다.

• 같은 양의 I/O작업을 하는데 Blocking IO모다 적은 스레드가 필요하다.

• 여러개의 I/O 요청이 Blocking IO에서 발생하면 각각의 call마다 스레드가 생성된다.

• 스레드를 생성하는 비용과 스레드간 context-switing이 발생하는것을 생각하면 비효율적인 측면이 있다.

non-blocking API는 요청 처리가 완료된것을 어떻게 통지할까?

• non-blocking API를 호출하면 호출측은 처리가 완료되었다는것을 반드시 알아야한다.
• 호출측은 어떻게 알게될까?
• CPU는 인스트럭션(명령어)을 순차적으로 처리한다. 어떻게 처리가 완료되었다는것을 통지할까?
• 운영체제 ready queue에 들어가지 않고 바로 응답을 한다. 바로 응답하기 힘든경우 에러를 반환하는데 정상데이터를 받을 때까지 계속해서 요청을 다시 보낸다.
• blocking 방식의 비효율적인 부분을 해결하기 위해서 non-blocking을 사용하는데 계속해서 요청을 다시 보내면서 자원을 낭비하게 된다(시스템 호출이 빈번하게 발생)

이벤트 통지 모델

매번 호출측에서 데이터가 준비되었는지 확인하는것을 비효율적이다. 수신 버퍼나 출력 버퍼측에서 이벤트롤 통지하면 어떨까? I/O 작업 결과 반환 방식에 따라 동기,비동기 모델로 구분할 수 있다.

Synchronous Model

• I/O 작업이 진행되는 동안 유저 프로세스는 결과를 기다렸다가 이벤트를 직접 처리하는 방식
• notify를 유저 프로세스(호출측)이 담당하여 주체적으로 진행하면 커널은 유저 프로세스의 요청에 수동적을 응답한다.

Asynchronous Model

• I/O 작업이 진행되는 동안 유저 프로세스 는 자신의 일을 하다가 이벤트 핸들러에 의해 알림이 오면 처리하는 방식이다.
• notify를 커널이 담당하여 주체적으로 진행(콜백을 넘겨주는 형태)하고 호출측은 수동적인 입장에서 통지가 오면 그때 I/O 결과를 반환 받는다.

Non-Blocking IO는 내부에서 어떻게 처리될까?

이벤트 루프

• 대부분의 non-blocking 프레임워크들은 무한루프를 통해 응답데이터가 존재하는지 지속적으로 확인한다.(poll) 이를 이벤트 루프라고 부른다
• 운영체제는 이벤트 루프를 생성하기 위해서 커널수준 API를 제공한다.
• 리눅스 epoll, io_uring (자바 NIO에서 윈도우는 select, 맥은 kqueue, 리눅스는 epoll을 지원)
• 윈도우 IOCP
• 이벤트 루프를 통해서 socket에서 읽을 데이터가 있는지 계속 확인한다.
• 유닉스 시스템에서 모든 파일,하드웨어 장치, 소켓등을 파일로 취급 (FD(File Descriptor))
  • FD 0번 : 표준 입력(키보드)
  • FD 1번 : 표준 출력
  • FD 2번 : 표준 에러
  • 3번부터는 사용자가 개설하는 소켓이나 불러오는 파일에 의해 배정
• 정확하게 이벤트 루프에서 FD에 데이터가 준비되었는지 확인