[Operating System] Chapter 3: Processes

Creating a Separate Process via Windows API Process Termination

 

프로세스는 마지막 명령을 실행한 후, OS에 의해 내부적으로 exit() system call을 호출합니다. 이때 해당 프로세스의 부모 프로세스는 wait()을 통해 자식 프로세스의 상태 정보를 얻을 수 있습니다. 그리고 OS는 해당 프로세스의 자원을 deallocation합니다.

 

부모 프로세스는 다음과 같은 이유로 자식 프로세스의 실행을 종료시킬 수 있습니다:

• Child has exceeded allocated resources; 자식 프로세스가 자원 할당량을 초과한 경우
• Task assigned to child is no longer required; 더 이상 자식 프로세스가 필요하지 않은 경우
• The parent is exiting and the operating systems does not allow a child to continue if its parent terminates; 부모 프로세스가 종료하는 경우 해당 프로세스의 자식 프로세스들도 종료될 수 있습니다. *not like Linux OS

 

마지막 예시의 경우 cascading termination이 발생합니다. 프로세스 계통(tree)상 부모 프로세스가 종료되면 그 아래에 위치한 자식 프로세스들과 그 자식의 자식 프로세스들 등등의 프로세스들이 종료됩니다. 이런 종료는 OS에 의해 발생합니다.

 

부모 프로세스는 wait()을 통해 자식 프로세스가 종료되는 것을 기다릴 수 있는데, 해당 system call은 상태정보와 종료되는 프로세스의 pid를 return합니다. (1) 만약 자식 프로세스가 종료되었을 때, 부모 프로세스가 wait()을 통해 자식 프로세스의 정보를 reaping하지 않는다면 자식 프로세스는 zombie가 됩니다. (2) 또한 자식 프로세스가 돌아가고 있는데, 부모 프로세스가 wait()을 호출하지 않고 먼저 종료한다면 자식 프로세스는 orphan이 됩니다. 이때 orphan들은 OS가 알아서 더 높은 부모 프로세스로 입양시켜주기도 합니다.

 

Multiprocess Architecture - Chorme Browser

 

현재도 몇몇 인터넷 브라우저들은 오직 하나의 프로세스로만 동작합니다. 하지만 Google Chrome Brower는 3종류의 프로세스들로 동작합니다.

• Browers; UI와 disk, network I/O를 담당하는 프로세스
• Renderer; web page와 HTML을 다루는 프로세스
  • 이때 sandbox는 disk나 network I/O를 제한함으로써 보안 등의 문제를 해결합니다.
• Plug-in;

Chrome Browers

 

Interprocess Communication

 

프로세스들은 independent하거나 cooperating합니다. 이들 중 coorperating하는 프로세스들은 data를 공유하는 등 다른 프로세스들에 의해 영향을 받습니다. 이런 coorperating process들을 만드는 이유는 다음과 같습니다:

• information sharing
• computation speedup
• modularity
• convenience

 

이런 coorperating processes들은 interprocess communication (IPC)가 필수적입니다. IPC를 수행하는 예시들 중 shared memory와 message passing에 대해 알아봅니다.

Communication models

 

Producer-Consumer Problem

 

먼저 producer-consumer문제에 대해 살펴보겠습니다. 이는 동기화 문제와 관련이 있습니다. message passing과 같은 IPC를 사용하는 경우 buffer를 기준으로 프로세스들이 소통합니다. 이때 buffer의 종류는 두 가지로 나눌 수 있습니다. (1) unbounded-buffer는 queue나 buffer에 공간 제약이 없는 경우입니다. 동기화 문제가 덜 합니다. 예를 들어 producer process가 데이터를 쓰려고하는 경우 buffer가 가득 차는 경우는 없습니다. 계속 늘어날 수 있기 때문입니다. (2) bounded-buffer는 queue나 buffer에 공간 제약이 있는 경우입니다. 이는 동기화 문제가 생길 수 있는데, 같은 예시로 데이터를 쓰려고 하는 경우 buffer가 가득 차서 데이터를 쓰지 못하는 경우가 발생할 수 있습니다.

 

Interprocess Communication - Shared Memory

 

shared memory는 소통하고자 하는 두 프로세스가 서로 공유하는 메모리 공간에서 소통하는 것을 말합니다. 이는 OS에 의해서 소통이 이뤄지지 않으며 사용자 control에 의해 소통이 이뤄집니다. *OS는 memory공간의 주소를 pointer로서 두 프로세스에게 제공하기만 합니다. 그 후의 동작들은 사용자에 의해서 이뤄집니다. 그러므로 사용자에 의해 동기화 문제가 발생할 수도 있습니다.

 

shared memory에서 발생하는 대부분의 문제는 communication에 참여하는 프로세스들이 하나의 데이터에 접근하고자 할때 발생하며 자세한 얘기는 Chapter 5에서 이뤄집니다.

 

Interprocess Communication - Message Passing

 

Message passing은 shared memory와 다르게 buffer가 kernel안에 위치하기 때문에 OS가 동기화 문제를 통제하기 쉽습니다. 이는 send(message)와 receive(message)라는 두 명령에 의해 제공됩니다. message의 크기는 고정된 크기를 갖을 수도 있고 가변 길이를 가질 수도 있습니다.

 

만약 프로세스 P와 Q가 소통을 원하는 경우 우선 (1) communication link를 이들 사이에 설치합니다. 이는 queue가 될 수도 있고, 임의의 자료구조 buffer가 될 수도 있습니다. (2) 그 후 이를 통해 메시지를 받거나 보냅니다.

 

이때 구현에 대한 issue들이 있습니다:

• how are links established?; 어떤 자료구조로 소통할 지를 정해야합니다.
• can a link be associated with more than two processes?; link에 참여하는 프로세스의 수를 정해야합니다.
• how many links can there be between every pair of communicating processes?; 여러개의 link를 설치할 수 있는지를 정해야합니다.
• what is the capacity of a link?
• is the size of a message that the link can accommodate fixed or variable?
• is a link unidirectional or bi-directional?

 

communication link를 구현할 때도 여러가지 옵션들이 존재합니다:

• Physical
  
  • shared memory
  • hardware bus
  • network
• Logical
  • Direct or indirect
  • Synchronus or asynchronus
  • Automatic or explicit buffering

 

Direct Communication

 

message passing에서 직접 소통의 경우 다음과 같은 명령어들을 사용할 수 있습니다:

• send(P, message) - send a message to process P; Process의 이름을 명확히 명시합니다. 이를 통해 direct communication임을 간접적으로 알 수 있습니다.
• receive(Q, message) - receive a message from process Q

 

이때 communication link의 특징은 다음과 같습니다:

• Links are established automatically; 프로세스가 소통을 원한다면 내부적으로 해당 프로세스들 사이에 link를 알아서 설치합니다.
• A link is associated with exactily one pair of communicating processes
• Between each pair there exists exactly one link; 두 프로세스 사이에 link는 오직 하나입니다.
• The link may be undirectional, but is usually bi-directional

 

Indirect Communication

 

두 프로세스들 사이의 소통은 queue같은 mailbox를 통해 이뤄집니다. 이때 mailbox는 unique한 id를 갖고, 각각의 프로세스들은 해당 mailbox를 공유하는 경우에만 메시지를 보낼 수 있습니다.

 

이때 communication link의 특징은 다음과 같습니다:

• Link extablished only if processes share a common mailbox; link는 오직 mailbox가 공유될 때만 형성됩니다.
• A link may be associated with many processes; 해당 mailbox는 공유 되기만 하면 여러 processes들 사이에서 소통을 매개할 수 있습니다.
• Each pair of processes may share several communication links; 각 프로세스들의 쌍은 여러개의 link를 공유할 수 있습니다.
• Link may be unidirectional or bi-directional

 

Indirect communication은 (1) 우선 새로운 mailbox를 생성한 후, (2) mailbox를 통해 메시지를 주고 받습니다. (3) 그 후 mailbox가 필요하지 않다면 삭제합니다. *이때 direct communication과 달리 명시적으로 mailbox를 생성합니다.

 

이때 사용하는 명령어는 다음과 같습니다:

• send(A, message) - send a message to mailbox A; direct한 방법과 달리 mailbox의 id를 명시하는 모습입니다.
• receive(A, message) - receive a message from mailbox A; 대상이 되는 process를 명시하지 않았으므로 아무나 받아라 느낌으로 전달하고 전달 받습니다.

 

이때 mailbox sharing문제가 발생할 수 있습니다. 예를 들어 P1, P2, P3가 A라는 mailbox를 공유하는 경우, P1이 메시지를 보냈을 때, P2와 P3가 동시에 receive를 요청하는 경우입니다.

 

이는 다음과 같은 해결 옵션이 존재합니다:

• Allow a link to be associated with at most two processes; P2와 P3가 자원을 경쟁하는 상황 자체가 사라짐
• Allow only one process at a time to execute a receive operation; 오직 하나의 프로세스만 receive명령을 할 수 있도록 함
• Allow the system to select arbitrarily the receiver. Sender is notified who the receiver was; 임의로 receiver를 설정합니다.

 

Synchronization

 

message passing의 경우 blocking과 non-blocking 방식이 있습니다. message passing에서는 blocking을 synchronous로, non-blocking을 asychronous로 간주할 수 있습니다.

• Blocking send - the sender is blocked until the message is received; 메시지가 receiver에 도착할 때까지 다음 명령을 수행할 수 없습니다.
• Blocking receiver - the receiver is blocked until a message is available; 메시지가 mailbox에 도착해서 receive할 수 있을 때까지 다음 명령을 수행할 수 없습니다.
• Non-blocking send - the sender sends the message and continue; 메시지를 보내고 그냥 다음 명령을 수행합니다. 이는 지금 msg를 보낼 수 있는지 없는지를 확인하는 정도로 사용됩니다.
• Non-blocking receive - the receiver receives:
  • A valid message (오류 메시지), or
  • Null message

 

서로 다른 종류의 방법을 조합할 수 있고, 만약 send와 receive가 모두 block방식이라면 이를 rendezvous (랑데뷰)라고 부릅니다.