Blocking I/O Model
I/O 작업은 User Level(application)에서 직접 수행할 수 없다. 실제 I/O작업은 Kernel Level(OS)에서 일어나는 과정이다. 따라서 유저 프로세스(application)는 커널(OS)에게 I/O작업에 대한 요청을 해야한다.
- I/O 작업을 처리하기 위해 User Level에 있던 Application이 시스템 함수를 호출한다(→ system call).
- 이 때 context-switching 이 발생한다.
- Kernel Level에서 해당 I/O 작업 진행, I/O가 끝날 때까지 유저 프로세스 대기
- 끝나기 전에는 함수가 반환되지 않기 때문에 커널이 작업을 완료하기전까지 유저 프로세스는 작업을 중단한 채 대기해야 한다. I/O 작업이 CPU 자원을 거의 쓰지 않기 때문에 Blocking 방법은 CPU 자원 낭비가 심하다.
- 애플리케이션 관점에서 보면 아무런 동작도 안하는 것처럼 보이지만 실제로는 커널에서 I/O 작업을 수행하느라 block되어 있는 것이다. 바로 이 부분이 blocking I/O의 문제점이며 개선 포인트다
- 이러한 blocking 방식의 비효율성을 극복하고자 만들어 진 것이 non-blocking 방식이다.
- 작업 완료 후 데이터를 반환하게 되면 그 때가 되어서야 Application단의 스레드에 걸렸던 block이 풀린다.
Non-Blocking I/O Model
non-blocking 방식은 I/O 작업을 진행하는 동안 유저 프로세스의 작업을 중단시키지 않는다.
- 유저 프로세스가 I/O를 처리하기 위해 커널에 함수를 호출하면(→ system call )
- 커널에서 함수의 진행 상황과 상관없이 바로 결과를 반환한다.
- 이 때 반환되는 결과는 반환하는 순간에 가져올 수 있는 데이터에 해당한다. 처음에는 가져올 수 있는 데이터가 없겠지만 시간이 지나면서 가져올 수 있는 데이터가 생겨날 것이다. 서버는 클라이언트가 요청한 사이즈에 맞는 데이터를 반환하기 위해 데이터를 축적한다.
- 클라이언트가 따로 반환되는 값이 원하는 사이즈가 되었는 지 계속해서 확인해준다. (→ polling )
- 반환되는 데이터가 준비가 되었는지(원하는 값이 되었는지) 확인하는 과정에서 수많은 클라이언트의 요청이 동시 다발적으로 일어날 경우, CPU에게 적지 않은 부담이 될 수 있는 I/O Model 이다.
- 데이터의 축적이 끝났을 때, 반환되어 클라이언트에서 요청한 사이즈의 데이터를 받아올 수 있게 된다.
I/O 작업을 진행하는 동안 유저 프로세스의 작업을 중단시킨다면
→ Blocking
I/O 작업을 진행하는 동안 유저 프로세스의 작업을 중단시키지 않는다면
→ Non-Blocking
Asynchronous I/O Model
Event-driven Model로도 불리는 이 모델은 Non-Blocking에서 제기된 문제를 해결하기 위해 고안되었다. Non-Blocking I/O Model에서 처럼 애플리케이션에서 데이터 준비가 되었는지 계속해서 확인하는 것이 아니라,
- 작업 요청
- 유저 프로세스는 다른 작업 수행
- kernel Level에서 데이터가 준비되면 콜백 또는 이벤트를 발생시켜 애플리케이션에 알림(→ notify )
- 그 때 그에 따른 작업 처리
운영체제 단계의 비동기 API를 통해 이루어지며 I/O작업이 completion이 되면 그에 적합한 Handler를 이용해 처리 한다.
system call이 반환될 때 실행된 결과(데이터)와 함께 반환될 경우
→ Non-Blocking
system call이 반환될 때 실행된 결과(데이터)와 함께 반환되지 않을 경우
→ Async
- Async 방식은 데이터를 콜백함수 또는 이벤트, signal로 전달하게 되는 것이며, Non-blocking 방식은 ao system call return 에 데이터가 포함되어, return 되는 데이터가 요청한 데이터가 전부 도달했는지를 파악하게 된다.
Synchronous
작업을 요청한 후 해당 작업의 결과가 나올 때까지 기다린 후 처리하는 것으로 I/O 작업에 대한 readiness를 기다린다. 특정 I/O 작업을 하기 위한 준비가 되었는지에 집중하는 것이다. I/O 작업 준비에 대한 이벤트의 발생을 기다렸다가 해당 이벤트가 발생하면 그에 따른 적합한 처리를 한다.
system call의 완료를 기다리면
→ Sync
system call의 완료를 기다리지 않으면
→ Async
시스템의 반환을 기다리는 동안 대기 큐에 머무는 것이 필수가 아니면
→ Synchronous
시스템의 반환을 기다리는 동안 대기 큐에 머무는 것이 필수라면
→ Blocking
⍞ Reference
'정리 log > 용어 · 개념' 카테고리의 다른 글
[OS] 가상 메모리 (0) | 2020.09.13 |
---|---|
[데이터베이스] 정규화 vs. 비정규화(반정규화) (1) | 2020.06.15 |
[OS] 메모리 관리 전략 (0) | 2020.05.28 |
[네트워크] 프로토콜 (0) | 2020.05.25 |
[네트워크] OSI 참조 모델, TCP/IP 모델 (0) | 2020.05.18 |
댓글