I. 기본개념
먼저 이 그림을 보고 갑시다.
기본적으로 I/O 작업은 user영역에서 직접 수행이 불가능합니다.
그러므로 User Process가 Kernel Space에게 I/O 작업을 요청하고 응답받는것이 기본적인 흐름입니다.
그리고 동기 비동기 설명을 하기전에 아래 문장을 전제로 이야기를 시작하겠습니다.
● 리눅스에서의 모든것은 파일이다!
(사실 정확하게는 파일이 아니라 바이트 스트림입니다.)
위의 이야기를 하는 이유는 다음과 같습니다.
입출력 작업을 위해 파일, 소켓, 디바이스, 파이프 등 모든 것을 바이트 스트림으로 다룬다는 이야기는, 통일된 인터페이스를 통해 다양한 작업을 수행할 수 있다 라는 중요한 개념을 내포합니다.
더 자세한 설명이 필요하다면 (링크)[https://ko.savtec.org/articles/howto/what-does-everything-is-a-file-mean-in-linux.html]를 봅시다!
1. 동기
▶ 모든 I/O 요청-응답 작업이 일련의 순서를 따릅니다. 즉, 작업의 순서가 보장됩니다.
▶ 작업 완료를 user space에서 판단하고 다음 작업을 언제 요청할지 결정하게 됩니다.
▶ 일련의 Pipeline을 준수하는 구조에서 효율적입니다
2. 비동기
▶ kernel에 I/O 작업을 요청해두고 다른 작업 처리가 가능하나, 작업의 순서는 보장되지 않습니다.
▶ 작업 완료를 kernel space에서 통보해 줍니다.
▶ 각 작업들이 독립적이거나, 작업 별 지연이 큰 경우 효율적입니다.
3. 블로킹
▶ 요청한 작업이 모두 완료될 때까지 기다렸다가 완료될 때 응답과 결과를 반환받습니다. (대기 有)
▶ 요청한 작업 결과를 기다립니다.
4. Non-Blocking, 넌-블로킹
▶ 작업 요청 이후 결과는 나중에 필요할 때 전달받습니다. (대기 無)
▶ 요청한 작업 결과를 기다리지 않습니다.
▶ 중간중간 필요하면 상태 확인은 해볼 수 있습니다. (polling)
- 동기 vs 비동기 : 처리해야 할 작업들을 어떠한 '흐름'으로 처리 할 것인가에 대한 관점
- 블로킹 vs 논블로킹 : 처리되어야 하는 (하나의) 작업이, 전체적인 작업 '흐름'을 막느냐 안막느냐에 대한 관점
II. 모델링
위의 커널영역 유저영역 이야기를 하기전에 한번 간단한 시나리오를 보고 깊게 파봅시다.
등장인물 : 팀장, 사원 똘비, 사원 똘순이, 사원 똘망이
시나리오1(비동기 + 논 블로킹)
- 팀장은 똘비와 똘순이 똘망이에게 각각 일 1,2,3을 지시하려고 합니다.
(비동기니까 각각 일을 시킬수 있습니다.)
1-1. 다행히 똘비와 똘순이, 똘망이가 별말이 없기에 각각에게 지시를 내립니다. - 똘비는 1의 일을 하고 똘순이는 2의 일을 똘망이는 3을 합니다. 팀장님은 팀장님 일을 하구요.
- 여기서 똘순이가 먼저 일이 다 끝났습니다.
- 팀장님이 이걸 확인하고 다음 일을 시키거나 혹은 개인공부를 하라고 지시합니다.(논블로킹 방식)
- 똘비가 일이 끝나면 팀장님께 확인받습니다.
아주 일반적인 회사의 상황입니다.
시나리오2(비동기 + 블로킹)
- 팀장은 똘비와 똘순이 똘망이에게 각각 일 1,2,3을 지시하려고 합니다.
(비동기니까 각각 일을 시킬수 있습니다.)
1-1. 여기서 똘비가 갑자기 팀장을 붙잡고 내가 일이 끝날때까지 뒤에서 업무를 봐달라고 사정사정을 합니다. (이게 블로킹입니다.)
1-2. 하는수 없이 팀장은 똘비의 뒤치다거리를 봐줍니다. - 이제 각각 일을 시키려고 하는데 이번에는 똘순이가 일2를 봐달라고 합니다.
2-1. 결국 마음씨 좋은 팀장님은 똘순이의 뒤치다거리를 봐줍니다. - 똘망이도 마찬가지일겁니다.
시나리오3(동기 + 블로킹)
- 팀장은 똘비에게만 일 1을 시킵니다. 똘순이와 똘망이는 그냥 놀고 있습니다.
(동기이기 때문에 각각 일을 못시킵니다.) - 똘비가 일 1이 끝날때까지 계속해서 모니터링합니다.
2-2. 여기서 똘비는 일이 끝날때까지 중간보고 없이 쭉 달립니다. - 똘비가 일 1이 끝나면 팀장님은 똘순이에게 갑니다. 이제 똘비와 똘망이는 그냥 놉니다.
- 팀장은 똘순이에게 일 2를 시킵니다.
- 똘순이가 일 2가 끝날때까지 팀장은 모니터링을 합니다.
(반복)
시나리오4(동기 + 논 블로킹)
- 팀장은 똘비에게만 일 1을 시킵니다. 똘순이와 똘망이는 그냥 놀고 있습니다.
(동기이기 때문에 각각 일을 못시킵니다.) - 똘비가 일 1이 끝날때까지 계속해서 모니터링합니다.
2-2. 여기서 똘비는 일 중간중간에 팀장님께 업무상황을 보고합니다. - 똘비가 일 1이 끝나면 팀장님은 똘순이에게 갑니다. 이제 똘비와 똘망이는 그냥 놉니다.
- 팀장은 똘순이에게 일 2를 시킵니다.
- 똘순이가 일 2가 끝날때까지 팀장은 모니터링을 합니다.
(반복)
이제 팀장을 User Process라고 생각하고 사원들을 커널이라고 생각해봅시다.
시나리오3(동기 + 블로킹)
User space에 존재하는 프로세스는 커널영역으로 I/O를 요청하는 함수를 호출합니다.
이때 커널이 작업결과를 반환하기전까지 User Process는 CPU를 점유하지 않으며 Kernel의 응답을 기다립니다.
이 과정에서 signal에 의해 시스템 콜이 중지될수는 있지만 그렇지 않으면 Kernle이 작업한 결과가 유저영역의 버퍼로 돌아오게 되며 이제서야 User Process는 다시 데이터를 처리가 가능합니다.
- Context Switching : 여러 개의 프로세스나 스레드가 동시에 실행될 때, 현재 실행 중인 프로세스 또는 스레드의 상태(Context)를 저장하고 다음 실행할 프로세스 또는 스레드의 상태를 복원하는 작업
시나리오4(동기 + 논 블로킹)
시나리오3와는 다르게 여기서는 User Space에 존재하는 프로세스가 커널영역으로 I/O를 요청하는 함수를 호출하는것까지는 같습니다.
중요한것은 커널이 중간중간에 보고를 한다는것이죠!
요청한 system call에 대해 kernel이 user process를 무한정 기다리게 하는 게 아니라 아직 덜됐으면 덜됐다고 물어볼 때마다 알려주는 것이기 때문에 논블로킹이라고 합니다.
이제 팀장을 User Process라고 생각하고 사원들을 파일 디스크립터라고 생각해봅시다.
I/O Multiplexing (멀티플렉싱, 다중화) = 시나리오2(비동기 + 블로킹)
먼저 파일 디스크립터(이하 FD)에 대한 개념을 설명해보겠습니다.
파일 디스크립터는 프로세스가 각각의 파일이나 소켓과 상호작용하기 위한 인터페이스이며, 각각의 파일 디스크립터는 프로세스 내에서 다양한 작업을 나타냅니다. 당연하지만 위에서 이야기했듯이 '리눅스는 모든것이 바이트스트림이다라는 기본개념' 때문에 파일 디스크립터 또한 바이트 스트림입니다.
파일은 파일디스크립터가 처리해야 하는 작업을 의미합니다.
(프로세스와 커널간에 인터페이스 역할을 하는것이 파일이라고 하는것은 정확하게는 바이트 스트림입니다.)
멀티플렉싱은 단일 프로세스나 스레드가 여러 개의 I/O 작업을 관리하면서, 이 작업들 중 어느 것이 준비되었는지를 감지하고 처리하는 기술입니다.
User Process가 팀장이라면 멀티플렉스는 FD를 어떻게 감시하느냐가 골자입니다. 즉 팀원 관리 노하우라고 이해하면 될것 같습니다.
그런데 머리가 아픈것은 블로킹이 되는것이 I/O에 관한것이 아닙니다.
멀티플렉싱 관련 system call에 대한 kernel의 응답이 블로킹이 된다는겁니다.
그러니까 쉽게 설명해보자면 다음과 같은겁니다.
- 먼저 User 영역의 특정 프로세스 A가 커널을 부릅니다. I/O 처리하기 위해서죠.
- 자 여기서 EWOULDBLOCK는 일종의 에러입니다. 데이터 검사를 했는데(CheckSum) 데이터가 뭔가 문제가 생겨서 버퍼에 저장이 안되는 상황이 발생하면 즉시 커널에서 프로세스로 중간보고를 하는거죠.(이것은 비동기 상황이니 이해가 갈겁니다.)
- 아무튼 에러나 타임아웃이 없다면 커널은 특정 유저영역에 있는 멀티플렉싱 함수를 불러와서 연산을 합니다. user process에서 루프를 돌며 대기하고 있습니다. 유의미한 결과가 나오기 전까지는요. 그리고 결과가 나오면 커널에게 이를 던집니다.
- 이어서 커널의 응답을 기다리다보면, 커널에서 결과 값이 준비되었다는 callback 신호가 오게됩니다. 그럼 user process는 자신의 buffer로 데이터를 복사해옵니다.(Read response 부분)
출처 : https://blog.naver.com/n_cloudplatform/222189669084
https://jiwondev.tistory.com/118
