[OS] IPC

IPC는 프로세스간 소통하는 방법이다. 프로세스는 independent 이거나 cooperating한다.

independent한 프로세스의 경우 다른 프로세스에 영향을 주지 않지만,

cooperating이 필요한 프로세스의 경우, 다른 프로세스에 영향을 주고받을 수 있다.

 

프로세스간 소통이라는게 말은 쉽지만, 일반적으로 프로세스에 할당된 메모리 공간은 해당 프로세스에 고유하기 때문에
다른 프로세스가 접근할 수 없다. 이를 문제를 해결하는 방법이 IPC이다.

 

IPC의 두 가지 모델

공유 메모리 (Shared Memory Model)

프로세스끼리 공유할 수 있는 메모리 공간을 생성하고 이 메모리를 통해 정보를 교환한다.

(조금더 자세히 말하면, 어떤 프로세스가 공유하고싶은 실제 메모리 공간을 참조하는 메모리 공간을 생성하여 실제 해당 프로세스의 메모리를 사용하는 것 처럼 보이게 한다)

공유 메모리를 생성, 삭제하거나 권한을 제어하는 등 초기 설정은 운영체제가 담당하지만,
공유 메모리에 어떤 형식의 데이터를 저장할지나, 공유 메모리를 통해 데이터를 읽고 쓰거나, 관리하는 책임은 각 프로세스들에게 있다.

 

운영체제가 초기 설정을 한 이후에는 커널의 도움이 필요 없기 때문에 속도가 빠르다는게 장점이지만,

공유 메모리를 통해 생산자 프로세스와 소비자 프로세스는 concurrent하게 통신하는데,

이 때 가용한 데이터가 있을 때만 소비가 이루어지도록 하려면 생산자/소비자 프로세스 간의 동기화가 필요하다는게 단점이다.

 

메시지 패싱 (Message Passing)

OS가 프로세스 간 통신 방법을 제공하고, 메시지 전달또한 대신 해준다.

공유 메모리 방식과 다르게 OS가 동기화를 관리해주기 때문에 동기화에 안전하지만, 시스템 콜을 사용하기 때문에 성능이 떨어진다.

(운영체제가 데이터를 send, receive하는 api를 제공해주고, send, receive에 대한 시스템 콜을 해주면 OS가 알아서 처리한다)

 

메시지 패싱 모델을 구분 기준에는 Direct/Indirect, Blocking/Non-Blocking이 있다.

 

- Direct 방식의 경우, 송수신 시 프로세스 서로의 이름을 명시해야한다. 프로세스 한 쌍에 하나의 링크만 존재하고, 1대1 통신에 사용된다.

- Indirect 방식의 경우, 중간의 메일박스(port)를 이용해 송수신이 이루어진다.

각 메일박스들은 고유한 id를 가지기 때문에, 어떤 메일박스로 메시지를 송수신하는지 명시할 수 있고, 그에따라 여러 프로세스가 메일 박스를 공유할 수 있다.

 

- Blocking send : 송신자는 수신자가 메시지를 받을 때 까지 대기한다.

- Non-Blocking send : 송신자는 비동기적으로 메시지를 보내고 자신의 할 일을 한다

- Blocking receive : 수신자는 메시지를 모두 다 받을때까지 대기한다.

- Non-Blocking receive : 수신자는 메시지가 다 오지 않더라도 대기하지 않고 메시지가 왔는지 수시로 확인한다.

 

IPC 종류

가장 원시적인 IPC 모델에 대해 봤으니, 이제 실제 쓰이는 IPC 방식에 대해 알아보자.

PIPE 방식

먼저 익명 파이프는 기본적으로 단방향 통신 채널이다. 한 쪽이 보내면, 반대쪽은 받기만 한다.

익명 파이프 방식은 부모자식 간에만 생성이 가능하고, 만약 양방향 통신을 하고싶으면 두 개의 파이프가 필요하다.

(이 경우, read와 write는 기본적으로 block 하게 작동한다)

 

기존의 익명 파이프의 단점인 같은 PPID(부모 프로세스의 PID)를 가지는 프로세스 간에만 적용할 수 있다는 점을 해결하기 위해,
Named PIPE라는 개념이 등장한다. Named PIPE는 "이름 있는 파일"을 파이프처럼 사용해 프로세스간 통신을 지원한다.

익명 파이프와 다르게 파이프 (파일) 의 이름만 알면 부모 자식간이 아니더라도 통신이 가능하다는 점이 특징이다.

나머지는 익명 파이프와 동일하게 기본적으로 undirectional하며, 읽고 쓰는 작업에 block이 적용된다.

 

Message Queues

read,write 방식은 Named PIPE 방식과 동일하다.

차이점이라고 하면, Named PIPE 방식이 데이터의 흐름이라면, 메시지큐 방식은 실제 메모리 공간을 사용한다는 점이다.

실제 메모리 공간을 사용하게 되면, 어디에서든 메시지를 꺼낼 수 있게되는데, 메시지큐에 write되는 데이터에는 고유 식별자가 붙게 되며,
해당 식별자를 통해 여러 개의 프로세스가 동시에 데이터를 다룰 수 있게 된다.

 

Memory Map

공유메모리 방식처럼 메모리를 공유하지만, 차이점은 "열린 파일" 을 메모리공간에 매핑시켜 공유한다는 것이다.

따라서 계속 파일을 열 필요 없이, 기존 메모리 공간에 접근해서 데이터를 읽고 쓸 수 있다.

 

Socket

파이프 개념을 네트워크로 확장시킨 것이다.

결국 인터넷 환경에서는 한 컴퓨터의 프로세스와 다른 컴퓨터의 프로세스가 통신해야하기 때문에,

IP와 포트 개념까지 확장하여 원격에서도 프로세스 간에 데이터를 공유한다.

 

RPC

만약 원격 프로세스 간 통신 환경 (소켓에서 말한 서로다른 컴퓨터의 프로세스 통신)에서 각 프로세스의 환경이 다른 경우

에를 들어 송신자의 컴퓨터가 64비트인데 수신자의 컴퓨터는 32비트인 경우에는,

stub라는 개념을 활용해 직접 원격에 있는 프로세스의 프로시저를 호출한다. (동일 시스템 내에서의 호출과는 다른 기법)

이부분은 나중에 gRPC에 대해 다룰 일이 있다면 더 자세히 다뤄보겠다.

(stubbing 자체가 gRPC 환경설정에서 필수적인 과정인데, 코드로 보면 더 잘 이해가 갈 것 같다)