3.6 IPC in Message-Passing Systems

 이 전의 방식들은 프로세스들이 메모리 영역을 공유하고, 공유 메모리에 액세스하고 조작하는 코드를 응용 프로그램 프로그래머가 명시적으로 작성해야 한다는 것을 요구한다 하지만 동일한 효과를 달성하기 위한 또 다른 방법이 있었다. 바로 Message-Passing 이다.

 이는 프로세스들이 동일한 주소 공간을 공유하지 않고도 통신하고 작업을 동기화하는 메커니즘을 제공한다. 통신하는 프로세스들이 네트워크로 연결된 다른 컴퓨터에 거주할 수 있는 분산 환경에서 특히 유용하다(프로세스간의 통신이 가능하기 때문). 메시지 전달 기능은 최소 두 가지 작업이 필요한데, send(message), receive(message) 이다.

 프로세스가 보낸 메시지는 고정된 크기이거나 가변적일 수 있다. 고정된 크기의 메시지만 전송할 수 있는 경우 시스템 수준의 구현은 간단하지만, 이를 사용하는 또 다른 프로그램의 구현을 더 어렵게 만든다. 반면에 가변적인, 동적인 메시지는 더 복잡한 시스템 수준의 구현을 필요로 하지만, 또 다른 프로그램의 구현에 더 유용하며 프로그래밍이 더 간단해진다. 이는 운영 체제 설계 전반에 걸쳐 볼 수 있는 일반적인 상충관계(trade-off)이다.

만약 process P와 Q가 통신을 하려고 할 때, 서로 메시지를 보내고 받아야 한다(그들 사이에 통신 링크가 존재해야한다). 이 물리적 링크는 여러가지 방법으로 구현할 수 있다(하지만 이건 물리 계층이기에 넘어감). 물리적 링크 대신에 우리가 만질 수 있는 것은 논리적인 링크 구현이다. 링크와 send()/receive() 작업을 논리적으로 구현하는 여러가지 방법이 있다.

• Direct or Indirect communication
• Synchronous or Asynchronous Communication
• Automatic or Explicit Buffering

 

 3.6.1 Naming

 통신을 원하는 프로세스들은 서로를 참조할 방법이 필요하다. 직접/간접 통신을 사용할 수 있는데, 직접 통신의 경우에 각 프로세스들은 명시적으로 통신의 수신자 혹은 발신자를 지정해야 한다. 이 체계에서 send()와 receive()의 premitives(프로그래밍에서 어떤 복잡한 프로그램을 만드는 데 사용될 수 있는 언어의 가장 기본적인 단위, 이는 광범위하게 사용할 수 있는데, 문자, 숫자, 요소, 기능 등등이다. 여기선 기본 작업 단위의 의미임), 기본 명령을 다음과 같이 정의한다.

• send(P, message) - 메시지를 프로세스 P로 보낸다
• receive(Q, message) - 프로세스 Q로부터 메시지를 받는다

이 방식의 통신 링크는 다음과 같은 특성을 가진다.

• 통신을 원하는 모든 프로세스 쌍 간에 자동으로 링크가 설정되며, 프로세스는 서로의 식별 정보(PID)를 알아야 통신을 할 수 있다.
• 링크는 정확히 두 개의 프로세스와 관련이 있다.
• 각 프로세스 쌍 간에 정확히 하나의 링크가 있다.

 이 방식은 주소 지정에서 symmetry를 보여준다. 즉, 송신 프로세스와 수신 프로세스 모두 통신을 위해 상대 프로세스를 명명해야 한다.

 이제 주소 지정에서 asymmetry를 사용하는 변형된 버전을 보자. 여기서는 송신자만 수신자를 명명하며, 수신자는 송신자를 명명할 필요가 없다. 이 방식에서는 다음과 같이 send() 및 receive() 기본 명령어가 정의된다.

• send(P, message) - 메시지를 프로세스 P로 보낸다.
• receive(id, message) - 모든 프로세스로부터 메시지를 수신하고, 변수 id는 통신이 발생한 프로세스의 이름으로 설정된다.

 이 두 방식의 단점은 생성되는 프로세스 정의의 제한된 모듈성이다. 이전 식별자에 대한 모든 참조를 찾아서 새 식별자로 수정해야 한다. 일반적으로 식별자를 명시적으로 지정해야 하는 이러한 hard-coding 기술은 간접적인 기술보다 선호되지가 않는다.

 indirect communication 에서는 메시지가 mailbox(port)로 전송되고 수신된다. 우편함은 프로세스에 의해 메시지를 넣을 수 있는 객체로 추상적으로 볼 수 있으며, 메시지를 제거할 수도 있다. 각 우편함은 고유한 식별자를 가지고 있다. 프로세스는 여러 다른 우편함들을 통해 다른 프로세스와 통신할 수 있지만, 두 프로세스가 공유 우편함을 가지고 있을 때만 통신할 수 있다. send() 및 receive() 기본 명령어는 다음과 같이 정의된다.

• send(A, message) - 메시지를 우편함 A로 보낸다
• receive(A, message) - 우편함 A로 부터 메시지를 수신한다

 이 방식에서 통신 링크는 다음과 같은 특성을 가진다

• 한 쌍의 프로세스 간에 링크가 설정되는 경우, 쌍의 모든 구성원이 공유 우편함을 가지고 있는 경우에 해당된다.
• 링크는 두 개 이상의 프로세스와 관련될 수 있다.
• 통신하는 각 프로세스 쌍 간에 서로 다른 링크가 존재할 수 있고, 각 링크는 한 개의 우편함에 해당한다.

 이제 프로세스 P1, P2, ... 등이 모두 우편함 A를 공유한다고 해보자. 프로세스 P1 은 A로 메시지를 보내고, P2와 P3 모두 A로 부터 receive()를 실행한다. 그러면 P1이 보낸 메시지를 받게 될 프로세스는 다음중 어떤 방법을 선택하냐에 따라 다른데,

• 링크가 최대 두 개의 프로세스와 연관되도록 허용한다.
• 한 번에 최대 한 프로세스만 receive 작업을 실행할 수 있도록 허용한다.
• 시스템이 메시지를 수신할 프로세스를 임의로 선택하도록 허용한다(즉, P2, P3 중 하나만이 메시지를 받지만 둘 다 받지는 않음). 시스템은 메시지를 수실할 프로세스를 선택하기 위한 알고리즘을 정의할 수 있다(프로세스가 메시지를 교대로 수신하는 순환 방식). 시스템은 송신자에게 수신자를 식별할 수 있다.

 Mailbox는 프로세스 또는 운여체제에 의해 소유될 수 있다. 만약 메일박스가 프로세스에 의해 소유된다면 우리는 소유자와 사용자를 구별한다. 각 메일 박스는 고유한 소유자를 가지고 있기 때문에 이 메일박스로 전송된 메시지를 어느 프로세스가 받아야 하는지 명확하다. 소유하는 프로세스가 종료되면, 메일박스가 사라진다. 그 이후에 해당 메일 박스로 메시지를 보내는 모든 프로세스는 해당 메일박스가 더 이상 존재하지 않음을 알려줘야 한다.

 이와 반대로, 운영체제에 의해 소유되는 메일박스는 자체적으로 독립적이며, 프로세스에 연결되어 있지 않다. 그래서 운영체제는 다음과 같은 기능을 수행할 수 있는 메커니즘을 제공해야 한다.

• 새로운 메일박스를 생성한다.
• 메일함을 통해 메시지를 보내고 받는다.
• 메일박스를 삭제한다.

새로운 메일박스를 생성하는 프로세스는 메일박스 소유자가 되는데, 처음에는 소유자만이 이 메일박스를 통해 수신할 수 있다. 하지만 적절한 시스템 호출을 통해 소유권과 수신 권한을 다른 프로세스로 전달할 수 있다. 이 규칙은 각 메일박스에 대해 여러 수신자가 발생할 수 있음을 의미한다.

 

3.6.2 Synchronization

 프로세스 간의 통신은 send()와 receive() 기본 명령어(premitive)를 호출하여 이루어진다. 각 프리미티브를 구현하는 데는 다양한 설계 옵션이 있고, 메시지 전달은 블로킹(blocking) 또는 논블로킹(nonblocking)일 수 있다. 이는 동기적(synchronous), 비동기적(asynchronous)으로도 부른다.

• blocking send: 전송 프로세스는 수신 프로세스 또는 메일 박스에 의해 수신될 때까지 차단된다.
• nonblocking send: 전송 프로세스는 메시지를 전송한 후에도 작업을 계속한다.
• blocking receive: 수신자는 메시지를 받을 때까지 차단된다.
• nonblocking receive: 수신자는 유효한 메시지나 null을 검색한다.

 send()와 receive()의 다양한 조합이 가능하다. send()와 receive()가 모두 블로킹인 경우, 송신자와 수신자 간의 랑데뷰(rendezvous)가 발생한다. blocking send()와 receive()를 사용할 때 생산자-소비자 문제의 해결은 간단해진다.

 

3.6.3 Buffering

 통신이 직접저긴지 간접적인지에 관계 없이, 통신하는 프로세스들 간에 교환되는 메시지는 일시적인 큐에 저장된다. 큐는 3가지 방식으로 구현되는데,

1. Zero Capacity: 큐의 최대 길이가 0이므로 링크에 대기중인 메시지가 없을 수 있다. 이 경우에는 발신자의 메시지가 수신자에게 전달될 때까지 차단되어야 한다.
2. Bounded Capacity: 큐의 길이가 유한하므로, 새 메시지가 전송될 때 큐가 가득차지 않은 경우, 메시지는 큐에 넣어지고(메시지가 복사되거나 메시지에 대한 포인터가 유지됨), 발신자는 대기하지 않고 실행을 계속할 수 있다. 하지만 링크의 용량은 유한하다. 큐가 가득찬 경우 발신자는 큐에 공간이 생길때까지 차단되어야 한다.
3. Unbounded Capacity: 큐의 길이가 잠재적으로 무한하므로, 발신자는 절대 차단되지 않는다.

용량이 0인 경우는 때로 버퍼링이 없는 메시지 시스템으로 간주된다. 다른 경우는 자동 버퍼링이 있는 시스템으로 참조된다.