[OS] 프로세스 간 통신(Interprocess Communication, IPC)

학습중인 교재

 

프로세스 간 통신(IPC)

---

운영체제 내에서 실행되는 병행 프로세스들은 독립적이거나 또는 협력적인 프로세스 들일 수 있습니다. 프로세스가 시스템에서 실행 중인 다른 프로세스들과 데이터를 공유하지 않는 프로세스는 독립적입니다. 프로세스가 시스템에서 실행 중인 다른 프로세스들에 영향을 주거나 받는다면 이는 협력적인 프로세스들입니다. 분명히 다른 프로세스들과 자료를 공유하는 프로세스는 상호 협력적인 프로세스입니다.

 프로세스 협력을 허용하는 환경을 제공하는 데는 몇 가지 이유가 있습니다.

• 정보 공유(information sharing): 여러 응용 프로그램이 동일한 정보(예를 들면, 복사와 붙여넣기)에 흥미를 느낄 수 있으므로, 그러한 정보를 병행적으로 접근할 수 있는 환경을 제공해야 한다.
• 계산 가속화(computation speedup): 만일 우리가 특정 태스크를 빨리 실행하고자 한다면, 우리는 그것을 서브태스크로 나누어 이들 각각이 다른 서브 태스크들과 병렬로 실행되게 해야 한다. 이러한 가속화는 복수 개의 처리 코어를 가진 경우에만 달성할 수 있음에 유의해라.
• 모듈성(modularity): 우리는 시스템 기능을 별도의 프로세스들 또는 스레드들로 나누어, 모듈식 형태로 시스템을 구성하기를 원할 수 있다.

 협력적 프로세스들은 데이터를 교환할 수 있는, 즉 서로 데이터를 보내거나 받을 수 있는 프로세스 간 통신(interprocess communication, IPC) 기법이 필요합니다. 프로세스 간 통신에는 기본적으로 공유 메모리(shared memory)와 메시지 전달(message passing)의 두 가지 모델이 있습니다. 공유 메모리 모델에서는 협력 프로세스들에 의해 공유되는 메모리의 영역으로 구축됩니다. 프로세스들은 그 영역에 데이터를 읽고 쓰고 함으로써 정보를 교환할 수 있습니다. 메시지 전달 모델에서는 통신이 협력 프로세스들 사이에 교환되는 메시지를 통하여 이루어집니다. 이 두 모델이 아래의 이미지에 대비되어 있습니다.

(a): 공뮤메모리, (B): 메시지 전달

 언급된 두 모델은 운영체제에서는 통상적이며 많은 시스템이 두 가지를 모두 구현합니다. 메시지 전달 모델은 충돌을 회피할 필요가 없기 때문에 적은양의 데이터를 교환하는데 유용합니다. 메시지 전달은 또한 분산 시스템에서 공유 메모리보다 구현하기 쉽습니다. 메시지 전달 시스템은 통상 시스템 콜을 사용하여 구현되므로 커널 간섭 등의 부가적인 시간 소비 작업이 필요하기 때문에 공유 메모리 모델이 메시지 전달보다 더 빠릅니다. 공유 메모리 시스템에서는 공유 메모리 영역을 구축할 때만 시스템 콜이 필요합니다. 공유 메모리 영역이 구축되면 모든 접근은 일반적인 메모리 접근으로 취급되어 커널의 도움이 필요 없습니다.

 

 

공유 메모리 시스템에서의 프로세스 간 통신(IPC in Shared-Memory Systems)

---

공유 메모리를 사용하는 프로세스 간 통신에서는 통신하는 프로세스들이 공유 메모리 영역을 구축해야 합니다. 통상 공유 메모리 영역은 공유 메모리 세그먼트를 생성하는 프로세스의 주소 공간에 위치합니다. 이 공유 메모리 세그먼트를 이용하여 통신하고자 하는 다른 프로세스들은 이 세그먼트를 자신의 주소 공간에 추가하여야 합니다. 일반적으로 운영체제는 한 프로세스가 다른 프로세스의 메모리에 접근하는 것을 금지한다는 것을 기억해야합니다. 공유 메모리는 둘 이상의 프로세스가 이 제약 조건을 제거하는 것에 동의하는 것을 필요로 합니다. 그런 후에 프로세스들은 공유 영역에 읽고 씀으로써 정보를 교환할 수 있습니다. 데이터의 형식과 위치는 이들 프로세스에 의해 결정되며 운영체제의 소관이 아닙니다. 또한 프로세스들은 동시에 동일한 위치에 쓰지 않도록 책임져야 합니다.

 협력하는 프로세스의 개념을 설명하기 위해서, 협력하는 프로세스의 일반적인 패러다임인 생산자-소비자 문제를 생각해 보기로 합시다. 생산자 프로세스는 정보를 생산하고 소비자 프로세스는 정보를 소비합니다. 예를 들어, 컴파일러는 어셈블리 코드를 생산하고, 어셈블러는 이것을 소비합니다. 어셈블러는 이어 목적 모듈(object module)을 생산할 수 있고, 적재기(loader)는 이들을 소비합니다. 생산자 소비자 문제는 클라이언트 서버 패러다임을 위한 유용한 은유를 제공합니다. 일반적으로 우리는 서버를 생산자로 클라이언트를 소비자로 생각합니다. 예를 들면 웹 서버는 HTML 파일과 이미지와 같은 웹 콘텐츠를 생산하고(즉, 제공하고) 이 자원들을 요청한 클라이언트 웹 브라우저가 소비하게 됩니다.(즉 읽는다)

 생산자-소비자 문제의 하나의 해결책은 공유 메모리를 사용하는 것입니다. 생산자와 소비자 프로세스들이 병행으로 실행되도록 하려면, 생산자가 정보를 채워넣고 소비자가 소모할 수 있는 항목들의 버퍼가 반드시 사용 가능해야 합니다. 이 버퍼는 생산자와 소비자가 공유하는 메모리 영역에 존재하게 됩니다. 생산자가 한 항목을 생산하고, 그동안에 소비자는 다른 항목을 소비할 수 있습니다. 생산자와 소비자가 반드시 동기화되어야 생산되지도 않은 항목들을 소비자가 시도하지 않을 것입니다.

 두 가지 유형의 버퍼가 사용됩니다. 무한 버퍼(unbounded buffer)의 생산자 소비자 문제에서는 버퍼의 크기에 실질적인 한계가 없습니다. 소비자는 새로운 항목을 기다려야만 할 수도 있지만, 생산자는 항상 새로운 항목을 생산할 수 있습니다. 유한 버퍼(bounded buffer)는 버퍼의 크기가 고정되어 있다고 가정합니다. 이 경우 버퍼가 비어 있으면 소비자는 반드시 대기해야 하며, 모든 버퍼가 채워져 있으면 생산자가 대기해야 합니다.

 유한 버퍼가 공유 메모리를 사용한 프로세스간 통신을 어떻게 분명하게 하는지 살펴봅시다. 다음 변수들은 생산자와 소비자 프로세스가 공유하는 메모리 영역에 존재합니다.

#define BUFFER SIZE 10

typedef struct {
	...
} item;

item buffer[BUFFER SIZE];
int in = 0;
int out = 0;

공유 버퍼는 두 개의 논리 포인터 in과 out을 갖는 원형 배열로 구현됩니다. 변수 in은 버퍼 내에서 다음으로 비어 있는 위치를 가리키며, out은 버퍼 내에서 첫 번째로 채워져 있는 위치를 가리킵니다. in==out; 일 때 버퍼는 비어 있고, ((in+1)% BUFFER_SIZE) == out)이면 버퍼는 가득 차 있습니다.

 생산자와 소비자의 코드가 아래에 나타나 있습니다.

공유 메모리를 사용한 생산자 프로세스

// 공유 메모리를 사용한 생산자 프로세스
item next produced;

while (true) {
	/* produce an item in next produced */
    
	while (((in + 1) % BUFFER SIZE) == out)
		; /* do nothing */
    
		buffer[in] = next produced;
		in = (in + 1) % BUFFER SIZE;
}

 

공유 메모리를 사용한 소비자 프로세스

// 공유 메모리를 사용한 소비자 프로세스
item next consumed;

while (true) {
	while (in == out)
    	; /* do nothing */
	next consumed = buffer[out];
    out = (out + 1) % BUFFER SIZE;
    
/* consume the item in next consumed */
}

생산자 프로세스는 next_Produced라는 지역 변수에 다음번 생상되는 item을 저장하고 있습니다. 소비자 코드는 next_Consumed라는 지역 변수에 다음번 소비되는 item을 저장하고 있습니다.

 이 방법은 최대 BUFFER_SIZE - 1 까지만을 버퍼에 수용할 수 있습니다. 

 

 

메시지 전달 시스템에서의 프로세스 간 통신(IPC in Message-Passing Systems)

---

바로 방금 서로 협력하는 프로세스가 공유 메모리 환경에서 어떻게 상호 통신을 행하는지 알아보았습니다. 그 기법은 프로세스들이 메모리 영역을 공유할 것을 필요로 하며, 공유 메모리에 접근하고 조작하는 코드가 응용 프로그래머에 의해 명시적으로 작성되어야 했습니다. 동일한 효과를 얻는 또 다른 방법으로 운영체제가 메시지 전달 설비를 통하여 서로 협력하는 프로세스 간의 통신 수단을 제공해 주는 방법이 있습니다.

 메시지 전달 방식은 동일한 주소 공간을 공유하지 않고도 프로세스들이 통신을 하고, 그들의 동작을 동기화할 수 있도록 허용하는 기법을 제공합니다. 메시지 전달 방식은 통신하는 프로세스들이 네트워크에 의해 연결된 다른 컴퓨터들에 존재할 수 있는 분산 환경에서 특히 유용합니다. 한 예로 월드 와이드 웹에 사용되는 chat 프로그램은 서로 메시지를 교환하여 통신하도록 설계될 수 있습니다.

 메시지 전달 시스템은 최소한 두 가지 연산을 제공합니다.

• send(message)
• receive(message)

프로세스가 보낸 메시지는 고정 길이일 수도 있고 가변 길이일 수도 있습니다. 고정 길이 메시지만 보낼 수 있다면, 시스템 수준의 구현은 직선적입니다. 그렇지만, 이러한 제한은 프로그래밍 작업을 더욱 힘들게 합니다. 반면에, 가변 길이 메시지는 보다 복잡한 시스템 수준의 구현이 있어야 하지만, 프로그래밍 작업은 더 간단해집니다. 이러한 일은 운영 체제 설계 전반에 걸쳐 흔히 볼 수 있는 교환입니다.

 만약 프로세스 P와 Q가 통신을 원하면, 반드시 서로 메시지를 보내고 받아야 합니다. 이들 사이에 통신 연결(communication link)이 설정되어야 합니다. 이 연결은 다양한 방법으로 구현할 수 있습니다. 우리는 연결의 물리적인 구현에 관심이 있는 것이 아니라, 논리적인 구현에 관심이 있습니다. 하나의 링크와 send() / receive() 연산을 논리적으로 구현하는 다수의 방법은 다음과 같습니다.

• 직접 또는 간접 통신
• 동기식 또는 비동기식 통신
• 자동 또는 명시적 버퍼링

다음으로 이 특성과 관련된 쟁점들을 살펴보겠습니다.

 

(1) 명명(Naming)

통신을 원하는 프로세스들은 서로를 가리킬 방법이 있어야 합니다. 이들은 간접 통신 또는 직접 통신을 사용할 수 있습니다.

 직접 통신하에서, 통신을 원하는 각 프로세스는 통신의 수신자 또는 송신자의 이름을 명시해야 합니다. 이 기법에서 send(), receive() 프리미티브들은 다음과 같이 정의합니다.

• send(P, message) - 프로세스 P에 메시지를 전송합니다.
• receive(Q, message) - 프로세스 Q로부터 메시지를 수신합니다.

이 기법에서 통신 연결은 다음의 특성을 가집니다.

• 통신을 원하는 각 프로세스의 쌍들 사이에 연결이 자동으로 구축된다. 프로세스들은 통신하기 위해 상대방의 신원(identity)만 알면 된다.
• 연결은 정확히 두 프로세스 사이에만 연관된다.
• 통신하는 프로세스들의 각 쌍 사이에는 정확하게 하나의 연결이 존재해야 한다.

 이 기법은 주소 방식에서 대칭성을 보입니다. 즉, 송신자와 수신자 프로세스가 모두 통신하려면 상대방의 이름을 제시해야 합니다. 이 기법의 변형으로서 주소 지정 시에 비대칭을 사용할 수도 있습니다. 송신자만 수신자 이름을 지명하며, 수신자는 송신자의 이름을 제시할 필요가 없습니다. 이 기법에서 send()와 receive() 프리미티브들을 다음과 같이 정의합니다.

• send(P, message) - 메시지를 프로세스 P에 전송한다.
• receive(id, message) - 임의의 프로세스로부터 메시지를 수신한다. 변수 id는 통신을 발생시킨 프로세스의 이름으로 설정된다.

 이들 기법(대칭적 그리고 비대칭적) 모두 프로세스를 지정하는 방식 때문에 모듈성을 제한한다는 것이 단점입니다. 프로세스의 이름을 바꾸면 모든 다른 프로세스 지정 부분을 검사할 필요가 있을 수 있습니다. 옛 이름들에 대한 모든 참조를 반드시 찾아서 새로운 이름으로 변경해야 할 것입니다. 일반적으로 이러한 하드 코딩(hard-coding) 기법은, 이 상황에서는 신원을 명시적으로 표시해야 합니다. 다음에 설명할 간접적인 방식에 비해 바람직하지 않습니다.

 간접 통신에서 메시지들은 메일박스(mailbox) 또는 포트(port)로 송신되고, 그것으로부터 수신됩니다. 메일박스는 추상적으로 프로세스들에 의해 메시지들이 넣어지고, 메시지들이 제거될 수 있는 객체라고도 볼 수 있습니다. 각 메일박스는 고유의 id를 가집니다. 예를 들어 POSIX 메시지 큐는 메일박스를 식별하기 위하여 정수 값을 사용합니다. 이 기법에서 프로세스는 다수의 상이한 메일박스를 통해 다른 프로세스들과 통신할 수 있습니다. 두 프로세스들이 공유 메일박스를 가질 때만 이들 프로세스가 통신할 수 있습니다. send()와 receive() 프리미티브들은 다음과 같이 정의할 수 있습니다.

• send(A, message) - 메시지를 메일박스 A로 송신한다.
• receive(A, message) - 메시지를 메일박스 A로부터 수신한다.

이 방법에서 통신 연결은 다음의 성질을 가집니다.

• 한 쌍의 프로세스들 사이의 연결은 이들 프로세스가 공유 메일박스를 가질 때만 구축됩니다.
• 연결은 두 개 이상의 프로세스들과 연관될 수 있습니다.
• 통신하고 있는 각 프로세스 사이에는 다수의 서로 다른 연결이 존재할 수 있고, 각 연결은 하나의 메일박스에 대응됩니다.

 프로세스 P1, P2, P3가 모두 메일박스 A를 공유한다고 가정해봅시다. 프로세스 P1은 메시지를 A에 송신하고, P2와 P3는 각각 A로부터 receive()를 실행합니다. 어느 프로세스가 P1이 보낸 메시지를 수신할까요? 이 문제에 대한 답은 우리가 선택할 기법에 좌우됩니다.

• 하나의 링크는 최대 두 개의 프로세스와 연관되도록 허용한다.
• 한순간에 최대로 하나의 프로세스가 receive() 연산을 실행하도록 허용한다.
• 어느 프로세스가 메시지를 수신할 것인지 시스템이 임의로 선택하도록 한다(즉, 두 프로세스 모두는 아니고 P2나 P3 중 하나가 메시지를 수신한다). 시스템이 어느 프로세스가 수신할 것인지를 선택하는 알고리즘을 정의할 수 있다(예를 들면, 라운드 로빈 방식에서는 프로세스가 돌아가면서 메시지를 수신한다). 시스템은 송신자에게 수신자를 알려 줄 수 있다.

메일박스는 한 프로세스 또는 운영체제에 의해 소유될 수 있습니다. 메일박스가 한 프로세스에 의해 소유된다면(즉, 메일박스가 프로세스의 주소 공간의 일부입니다), 우리는 소유자(이 메일박스로부터 메시지를 수신만 가능한 프로세스)와 메일박스의 사용자를(메일박스에 메시지를 송신만 할 수 있는 프로세스) 구분할 수 있습니다. 각 메일박스가 고유한 소유자를 가지고 있기 때문에, 이 메일박스로 보내진 메시지를 어느 프로세스가 수신할지에 대한 혼란이 생기지 않습니다. 메일박스를 소유하고 있는 프로세스가 종료할 때, 메일 박스는 사라집니다. 그 후에 이 메일박스로 메시지를 송신하는 모든 프로세스는 더는 메일박스가 존재하지 않는다는 사실을 반드시 통보받아야 합니다.

 반면에, 운영체제가 소유한 메일박스는 자체적으로 존재합니다. 이것은 독립적인 것으로 어떤 특정한 프로세스에 예속되지 않습니다. 운영체제는 한 프로세스에 다음을 할 수 있도록 허용하는 기법을 반드시 제공해야 합니다.

• 새로운 메일박스를 생성한다.
• 메일박스를 통해 메시지를 송신하고 수신한다.
• 메일박스를 삭제한다.

새로운 메일박스를 생성하는 프로세스는 디폴트로 메일박스의 소유자가 됩니다. 초기에는, 소유자만이 이 메일박스를 통해 메시지를 수신할 수 있는 유일한 프로세스였습니다. 그러나 소유권과 수신 특권의 적절한 시스템 콜을 통해 다른 프로세스에 전달될 수 있습니다. 물론 이런 규칙으로 인해 메일박스마다 복수의 수신자들을 낳을 수 있습니다.

 

(2) 동기화(Synchronization)

프로세스 간의 통신은 send와 receive 프리미티브에 대한 호출에 의해 발생합니다. 각 프리미티브를 구현하기 위한 서로 다른 설계 옵션이 있습니다. 메시지 전달은 봉쇄형(blocking)이거나 비 봉쇄형(nonblocking) 방식으로 전달됩니다. 이 두 방식은 각각 동기식, 비동기식이라고도 알려져 있습니다.

• 봉쇄형 보내기: 송신하는 프로세스는 메시지가 수신 프로세스 또는 메일박스에 의해 수신될 때까지 봉쇄된다.
• 비봉쇄형 보내기: 송신하는 프로세스가 메시지를 보내고 작업을 재시작한다.
• 봉쇄형 받기: 메시지가 이용 가능할 때까지 수신 프로세스가 봉쇄된다.
• 비봉쇄형 받기: 송신하는 프로세스가 유요한 메시지 또는 널(null)을 받는다.

 send()와 reeive()의 다른 조합도 가능합니다. send()와 receive()가 모두 봉쇄형일 때, 우리는 송신자와 수신자 간에 랑데부(rendezvous)를 하게 됩니다. 봉쇄형 send()와 receive()를 사용한다면 생산자와 소비자 문제에 대한 해결책은 사소한 문제가 됩니다. 생산자는 단순히 봉쇄형 send()를 호출하고 메시지가 수신자 또는 메일박스에 전달될 때까지 기다립니다. 유사하게 소비자가 receive()를 호출하면 메시지가 전달될 때까지 봉쇄됩니다. 아래의 두 코드가 이 동작을 설명하고 있습니다.

메시지 전달을 사용하는 생산자 프로세스

message next produced;

while (true) {
	/* produce an item in next produced */
	send(next produced);
}

 

메시지 전달을 사용하는 소비자 프로세스

message next consumed;

while (true) {
	receive(next consumed);
    
	/* consume the item in next consumed */
}

 

(3) 버퍼링(Buffering)

통신이 직접적이든 간접적이든 간에, 통신하는 프로세스들에 의해 교환되는 메시지는 임시 큐에 들어 있습니다. 기본적으로 이러한 큐를 구현하는 방식은 세 가지가 있습니다.

• 무용량(zero capacity): 큐의 최대 길이가 0이다. 즉, 링크는 자체 안에 대기하는 메시지들을 가질 수 없다. 이 경우에, 송신자는 수신자가 메시지를 수신할 때까지 기다려야 한다.
• 유한 용량(bounded capacity): 큐는 유일한 길이 n을 가진다. 즉 최대 n개의 메시지가 그 안에 들어 있을 수 있다. 새로운 메시지가 전송될 때 큐가 꽉 차지 않았다면, 메시지는 큐에 놓이며(메시지가 복사되든지 또는 메시지에 대한 포인터가 유지된다), 송신자는 대기하지 않고 실행을 계속한다. 그렇지만, 링크는 유한한 용량을 가진다. 링크가 꽉 차면, 송신자는 큐 안에 공간이 이용 가능할 때까지 반드시 봉쇄되어야 한다.
• 무한 용량(unbounded capacity): 큐는 잠재적으로 무한한 길이를 가진다. 따라서 메시지들이 얼마든지 큐 안에서 대기할 수 있다. 송싱자는 절대 봉쇄되지 않는다.

무용량의 경우는 때때로 버퍼가 없는 메시지 시스템이라고 부릅니다. 다른 경우들은 자동 버퍼링이라고 불립니다.