I/O 논블로킹이란 무엇일까?

 

논 블로킹에 대해 알아보기 전에 먼저 블로킹이 뭔지 알아보자!!

1. 커널

• 리눅스 커널은 리눅스 운영 체제의 주요 구성요소이며 컴퓨터 하드웨어, 프로세스를 잇는 핵심 인터페이스이다.
• OS 내에 위치하고 전화기, 노트북, 서버 또는 컴퓨터 유형에 상관없이 하드웨어의 모든 주요 기능을 제어한다.

커널의 4가지 기능

• 메모리 관리
  : 메모리가 어디에서 무엇을 저장하는 데 얼마나 사용되는 지 추적
• 프로세스 관리
  : 어느 프로세스가 중앙처리장치(cpu) 를 언제, 얼마나 오랫동안 사용할 지 결정
• 장치 드라이버
  : 하드웨어와 프로세스 사이에서 중재자/인터프리너 역할 수행
• 시스템 호출 및 보안
  : 프로세스의 서비스 요청을 수신

2. I/O

• I/O는 Input/Output의 약자이다. 주로 파일 입출력을 다룰 때 쓰인다.
• 네트워크에서도 볼 수 있는 데 소켓의 read/send로 생각하면 쉽다.
• 사용자 레벨에서 직접 수행 불가능, 실제 I/O는 커널에서만 가능
  • 사용자 프로세스(쓰레드)는 커널에게 I/0 요청 해야함

ex) 컴퓨터가 2대 이상 있다고 가정하고 서로 네트워크 통신을 한다면 한 컴퓨터에서는 출력(send)을 하고, 다른 컴퓨터는 입력(read) 받는 과정을 통해 통신하는 것이다.

I/0 작업은 User에서 직접 수행은 할 수 없다.

실제 I/O 작업은 Kernal(커넬 레벨)에서만 가능하다.

유저 프로세스(스레드)는 커널에게 요청을 하고 작업 완료 후 커널이 반환하는 결과를 기다린다.

3. Blocking Model

가장 기본적인 I/O 모델로 리눅스에서 모든 소켓 통신은 기본 블로킹으로 동작한다.
I/O 작업이 진행되는 동안에는 유저 프로세스는 자신의 작업을 중단하고 대기한다.

순서

1. 유저는 커널에게 (유저 -> 커널) READ 작업을 요청
2. 데이터가 입력될 때까지 대기
3. 데이터가 입력되면 유저에게 (커널 -> 유저) 결과가 전달되어야만 유저 자신의 작업에 다시 복귀

말 그대로 블록이 되고 어플레케이션에서 다른 작업을 수행하지 못하고 대기하게 되어 자원이 낭비되는 것을 볼 수 있다.

한마디 정리 : 애플리케이션 실행시 운영체제 대기 큐에 들어가면서 요청에 대한 system call이 완료된 후 응답을 보냄

4. Non-Blocking Model

위와 같은 블로킹 방식의 비효율성을 극복하고자 도입되었다.
I/O 작업이 진행되는 동안 유저 프로세스의 작업을 중단시키지 않는 방식이다.

순서

1. 유저가 커널에게 READ 작업 요청
2. 데이터가 입력여부와 상관없이 요청하는 그 순간 바로 결과를 반환한다. (만약 입력데이터가 없다면 결과메세지 {EWOULDBLOCK}를 반환 )
3. 입력데이터가 있을 때까지 1,2 번을 반복한다. (2번에서 결과 메세지를 받은 유저는 다른 작업 진행이 가능하다)
4. 입력 데이터가 있으면 유저에게 결과가 전달된다. (커널 -> 유저)

논 블로킹은 진행시간과 관계가 없어(대기 X) 어플리케이션에서 작업을 오랜 시간 중지하지 않고도 I/O작업을 진행할 수 있다. 그러나 반복적으로 시스템 호출이 발생하는 자원 낭비 문제가 있다.

한마디 정리 : 애플리케이션 실행 시 운영체제 대기 큐에 들어가지 않고, 실행 여부와 관계없이 바로 응답을 보낸다. 만약 바로 응답이 힘든 경우, 에러를 반환해 정상데이터를 받을 깨까지 계속 요청을 다시 보낸다.

 

정리 

 Blocking와 Non-Bolcking에 대해 간단히 정리하자면 다른 주체가 작업할 때 자신의 제어권이 있는지 없는 지로 볼 수 있다.

 

Synchronous (동기)

: 작업을 동시에 수행하거나, 동시에 끝나거나, 끝나는 동시에 시작함 

 

Asynchronous(비동기)

: 시작, 종료가 일치하지 않고, 끝나는 동시에 시작하지 않음

 

Blocking vs Non-Bolcking 

제어의 관점 

 

Sync vs Async 

순서와 결과의 관점

 

IO 이벤트 통지모델

• 논블로킹에서 제기된 문제를 해결하기 위해 고안
• IO이벤트를 통지하는 방법은 크게 2가지가 있다.

1. 동기 : 시스템 콜을 기다림 (notify를 사용자 프로세스가 담당) 시스템의 반환을 기다리는 동안 대기 큐에 머무는 것이 필수가 아니다 (블로킹은 필수로 머물러야 한다 )
2. 비동기 : 시스템 콜을 기다리지 않음 (notify를 커널이 담당) 요청에 대해 처리완료 여부에 관련없이 응답하고 다음 코드를 돌린다. 이후 OS 에서 처리완료여부 알려주고 응답함

동기 블로킹

• 프로그램이 블로킹을 일으키는 시스템 함수 호출 
• 한 작업 당 한 번의 사용자 - 커널 사이의 문맥교환 발생 
• 정지된 프로그램은 CPU 사용않고 커널의 응답 대기 
• 프로그램 관점에서 보면 처리로직이 오래걸리는 것 같다. 하지만 커널의 일을 기다리느라 블록되어 있는 ( 개선 포인트) 

비동기 블로킹 

 

• I/O는 논블로킹이고 알림이 블로킹인 방식 
• SELECT() 시스템하루 호출이 사용자 프로세스를 블로킹한다. 
• 비효율적 

 

비동기 논블로킹 

 

 

 

• 시스템콜이 즉시 IO개시 여부를 반환 
• 사용자 프로세스는 다른 일 가능 (CPU가 다른 업무 볼 수 있다. ) 
• IO는 백그라운드에서 처리 
• IO 응답이 도착하면 신호, 콜백으로 IO전달 완료 

 

 

 

 

참고
https://ju3un.github.io/network-basic-1/
https://sjh836.tistory.com/109

IO모델 (동기vs비동기vs블로킹vs논블로킹)

https://m.gettyimagesbank.com/view/blocking/1029317232