일단 (blocking io, non-blocking io, sync, async)공통적으로 IO는 user-space aplication 에서 직접 수행 될 수 없고 IO를 수행하기 위해서는 결국 커널에 한번 이상 시스템 콜을 보내야한다. 시스템 콜을 보내게되면 그 순간에 커널로 제어권이 넘어가고(context-switch), 유저 프로세스(or 스레드)는 제어권이 다시 돌아 오기 전에는 block이 된다. 쉽게 말하자면 block 이 되어 있는 동안 유저프로세스는 다른 작업을 하지 못하게 된다.
📌 sync blocking IO
- 시스템 콜이 들어오면, 커널은 IO 작업이 완료되기전에는 응답을 하지않는다.
- 즉 IO 작업이 완료되기전에는 제어권을 커널이 갖고있는다
- 그렇기에 시스템 콜을 보낸후에, 유저 프로세스는 응답을 받기 전에는 block이 되어 다른 작업을 하지못한다. 즉 IO 작업이 완료되기 전에는 다른 작업을 수행하지 못한다.
📌 sync non-blocking IO
- 시스템 콜이 들어오면, 커널은 IO 작업의 완료 여부와는 무관하게 즉시 응답을 해준다. (완료 되지않았다면 에러코드를 응답함.)
- 이는 커널이 시스템 콜을 받자마자 제어권을 다시 유저 프로세스에게 넘겨 준다는 것이기에, 유저 프로세스는 IO 가 완료 되기 전에도 다른 작업을 할수있는 것이다.
- 유저 프로세스는 다른 작업들을 수행하다가 중간 중간에 시스템 콜을 보내서 IO가 완료되었는지 커널에게 물어보게된다.
📌 async blocking IO
- 이 모델에서는 IO는 non-blocking이지만, 통지(notification)는 blocking 방식으로 하도록 되어있다.
- select() 는 유저 프로세스를 block 한다.
- select() 는 데이터가 사용이 가능해지면, 통지를 받게됨. 통지를 받으면 block을 품
📌 async non-blocking IO
-
시스템 콜이 들어오면, 커널은 IO 작업의 완료 여부와는 무관하게 즉시 응답을 해준다.
-
유저 프로세스는 IO 가 완료 되기 전에도 다른 작업을 할수있는 것이다.
-
IO 처리는 백그라운드에서 실행되다가, 완료되면 커널이 유저 프로세스에게 알려줌.
- 이는 sync non-blocking IO와의 차별점이라고 볼수있다.
- sync nonblocking IO는 유저 프로세스가 IO 완료 여부를 커널에게 계속 물어봐야 했지만,
- async non-blocking IO는 IO 완료가 되면 그때 커널이 유저프로세스에게 알려주는 방식이므로
🧩 Reference
꿈꿈