[CS] IPC

얄루얄루·2022년 9월 11일

Operating System

Computer Science

목록 보기

7/10

InterProcess communication (IPC)

다음의 이유로 IPC 기법의 필요성이 생긴다.

프로세스는 다른 프로세스의 공간에 접근할 수 없다.
성능을 높이기 위해 여러 프로세스를 만들어서 동시 실행 시, 프로세스 간 상태 확인 및 데이터 송수신이 필요하다.

해서, 파일을 통해서든 커널을 통해서든 어떻게든 통신을 할 수 있는 여러 방법들이 생겨났다.

IPC 기법으로는

Shared Memory (커널)
Message Queue (커널)
Pipe (커널)
Signal (함수 콜해서 정보 전송)
Socket (소켓 통해 정보 전송)

등이 있다.

프로세스 구조

프로세스는 위 사진과 같이

커널 영역
유저 영역

으로 구분되어 있다.

또한, 커널 영역 내에서

Physical memory
Kernel code and data

부분은 모든 프로세스가 동일하다.

애초에 이전에 설명했듯이 프로세스의 생성은 부모 프로세스의 forking을 통해 이루어지기 때문에 처음 생성되었을 때는 모든 값이 같다. 이후에 필요한 부분의 데이터를 교체하여 새로운 프로세스를 돌리는 것이다.

핵심은,

모든 프로세스가 동일한 내용을 가지고 있는 부분이 있다는 것
같은 내용을 죄다 복사해서 붙여넣는 것은 비효율적이라는 것
그렇기 때문에 커널 내부에 모든 프로세스가 공유하는 부분이 있다는 것
그래서 커널 or 다른 방법들을 통해 소통을 할 수 있다는 것

이 정도가 되겠다.

Shared Memory

커널에 의해 생성된 메모리 공간을 프로세스의 데이터 부분에 매핑해 두고 공용 메모리처럼 사용하는 방식이다. 메모리 접근을 통해 데이터를 공유하기 때문에 빠른 것이 특징이다.

작동 방식은 다음과 같다.
1. Writer 프로세스가 공유 메모리에 데이터를 쓴다
2. 데이터 쓰기가 완료되면 해당 데이터가 타 프로세스에 대해 접근 가능 상태가 된다.
3. Reader 프로세스가 공유 메모리에서 데이터를 가져다 쓴다.

Semaphore

Shared Memory를 이용한 IPC를 하려면 한 가지 유의해야 할 것이 있다.

Race conditon에 취약해 질 수 있다는 것인데, 아래 그림을 보자.

그림에는 Thread로 나와있지만, Process로 이해해도 문제 없다. 둘 다 같은 현상이 발생하니까.

그림을 보면,

먼저 T1에서 Y에서 값 5를 읽었다.
그리고 Context switching에 의해 T2가 running 상태로 들어가고
다시금 정해진 명령에 따라 Y에서 값을 읽었는데, 변경이 없었으므로 당연히 5를 읽게 된다.
이후 *2를 한 값 10을 저장한다.
다시 Context switching이 일어난다.
T1이 가지고 있던 값은 1번에서 읽은 5였으므로 5+1인 6이 최종적으로 저장된다.

왜 이런 일이 생기느냐?

프로세서는 각 작업의 묶음 단위가 무엇인지 모른다.

Y = Y + 1;

라는 Statement도 Instruction level로 들어가면

Load Y;
ADD Y 1;
SAV Y;

대강 이렇게 3단계로 구분될 수 있을 것이다.

이때 프로세서는 이 3개의 작업이 한 세트라는 것을 인지하지 못하고 Load Y;를 실행한 이후 툭 끊어버리고 분별없는 Context Switching을 해버리는 것이다.

세트로 이루어져야 할 작업이 그러지 못하니 결과적으로 값이 이상하게 덮어씌워지게 된다.

이런 현상을 막기 위해서는 공유되는 자원의 접근 권한을 통제하면 되는데,

이를 Mutual exclusion (상호 배제)라고 한다.

Race conditon을 발생시킬 수 있는 공유 자원, Critical section에 대해 하나의 프로세스가 접근하면 lock() 메소드를 이용해 다른 프로세스의 접근을 불허하는 것이다.

이렇게 되면, 다른 프로세스는 필요한 자원을 얻지 못하니 실행되지 못하고 자연스레 Waiting 상태가 되어 현 작업이 끝나기를 기다려야 한다.

이 방법의 장점은 동기화 이슈를 해결 할 수 있다는 것이지만,

단점은 이렇게 되면 멀티 태스킹을 하는 의미가 적어진다. 여러개의 프로세스가 동시에 같은 작업을 해서 빨리 끝내는 것이 목적인데, 해당 작업은 한 번에 하나의 프로세스만 할 수 있다? 물론 Critical section을 이용하지 않는 작업을 할 때에는 멀티 태스킹의 장점을 가져갈 수 있겠지만 효율성이 떨어진다고 할 수 있겠다.

아무튼 Critical section에 대해 한 번에 무조건 하나의 프로세스만 접근이 가능한 방법과, N개의 프로세스가 접근 가능하도록 하는 방법이 있다. 이를 각각,

Mutex or Binary Semaphore
Counting Semaphore

라고 한다.

Message Queue

메세지 큐는 커널 내에 위치하고 있으며, 공유 메모리를 사용하지 않는 환경에서 메시지를 담는 버퍼 역할을 한다. 공유 메모리와의 차이점은 커널을 경유한다는 등 여러가지가 있겠지만, 무엇보다도 메세지 큐이기 때문에 하나의 메세지를 받을 수 있는 것은 하나의 프로세스 뿐이라는 것이 있다.

작동 방식은 다음과 같다.
1. 프로세스 P1이 P2에 데이터를 보내기 위해 시스템 콜을 사용한다.
2. 시스템 콜에 의해 P1의 주소 영역에서 메세지가 카피되어 커널에 보내진다.
3. 이후, P2가 데이터를 받기 위해 시스템 콜을 사용한다.
4. 메세지 큐의 메세지가 커널에서 P2의 주소 영역으로 보내진다.

Pipe

부모-자식 관계의 프로세스 간에 이루어지는 단방향 통신이다.
Pipe는 입출력 방향이 제한 된 Deque로 이해하면 편하다. Pipe는 pipe system call을 이용해 생성 할 수 있고, 기본적으로 방향 제어를 위해 한쪽은 Write, 다른 한쪽은 Read가 Block되지만 Pipe가 full 상태라면 하나 남은 Write 마저도 Block 되고, Pipe가 empty 상태라면 하나 있던 Read도 Block이 된다.

만일 양 방향으로 통신을 하고 싶다면, 그림에서와 같이 2개의 Pipe를 사용해야 한다.

Pipe의 단점은 메세지 큐와 마찬가지로 하나의 프로세스에 밖에 데이터를 보낼 수 없다는 것도 있겠지만, 그보다 더 명백한 단점은