[운영체제] 프로세스

프로세스

현재 실행 중에 있는 프로그램으로, 프로그램을 실행하기 위해 필요한 많은 정보들을 포함한다.

• Text Section
  : 실행 대상이 되는 프로그램의 코드.
• Program Counter
  : 실행 중인 현재 위치를 알리는 프로세서 레지스터
• Stack
  : 특정 시점의 실행 환경 정보를 담기 위한 자료구조이다.
  재귀함수를 실행하는 경우, 재귀호출할 때마다 현재 함수 환경의 정보를 funtion frame 형태로 만들어 현재 파라미터, 리턴 값, 로컬 변수 혹은 레지스터에 저장된 값 등 다양한 정보를 저장하고, 이를 보관해야 후에 해당 함수를 다시 호출 할 수 있게 되는데, 이때 사용되는 자료구조가 Stack 이다.
• Data Section
   : 전역 변수를 저장하는 공간.
• Heap
   : 동적 메모리 할당을 위해 사용되는 공간.

스택과 힙 사이의 공간은 비어있는 공간으로, 스택 및 힙 크기의 증가에 따라 증감한다.

Text / Data Section 의 경우, 프로그램을 시작하는 시점에 크기가 고정되므로 크기가 변하지 않는다. 

 

프로그램과 프로세스의 차이

• 프로그램 : 디스크 상에 저장되어 있는 실행 파일. passive entity
• 프로세스 : 프로그램이 로더에 의해 메모리에 적재되어 활동할 수 있는 상태로, 하나의 프로그램이 반드시 하나의 프로세스에 대응되는 것은 아니고, GUI 영역 - 계산 영역 등 각자의 영역을 맡는 다양한 프로세스로 구성될 수도 있다.

 

프로세스의 상태 (Process State)

프로세스가 생성된 이후부터 프로세스의 상태는 계속해서 변할 수 있다.

• New
  : 프로세스가 생성된 상태. 새로운 프로세스가 메모리 상에 적재되어 다양한 정보( Data, Text ... ) 를 얻은 상태
  • New -> Ready ( admitted ) : 프로세스가 ready queue에 들어갈지 결정.
• Ready
  : 프로세스가 실제 컴퓨터에서 실행될 수 있도록 대기하는 상태. 일종의 줄서서 자신의 순서를 기다리는 상태
  
  • -> Running ( scheduler dispatch ) : 스케줄링에 의해 프로세스가 실행 상태로 이동
• Running
  : 실제로 CPU 스케줄링을 통해 프로세스가 CPU에 할당되어 실행중인 상태
  • -> Ready ( interrupt ) : 이벤트가 발생하여 프로세스에게 순서 넘김.
  • -> Waiting ( I/O or event wait ) : 특정 이벤트가 실행될 때까지 실행되지 않고 대기
  • -> Terminated ( exit ) : 프로세스가 작업을 마치고 실행을 끝냄
• Waiting
  : 특정 이벤트가 발생하여( I/O 등 ) 다른 이벤트가 발생할 때까지( I/O 완료 ) 대기하는 상태
  • ->Ready ( I/O, event completion ) : 이벤트를 만족하여 다시 실행될 수 있음
• Terminated
  : 프로세스가 종료되는 상태.

프로세스 컨트롤 블록(PCB)

각각의 프로세스를 관리하고 동작시키기 위한 정보를 저장해두는 블럭으로, Task Control Block 이라고 부르기도 한다.

• Process State
  : 프로세스가 현재 가지고 있는 상태
• Process Number
  : 프로세스에 부여된 id
• Program Counter
  : 다음 실행 될 instruction 주소
• Registers
  : 특정 프로세스에 대해 지정된 레지스터 값
• Memory Limits
  : 일종의 보안을 위한 장치로, 각 프로세스가 접근할 수 있는 메모리 영역을 제한. 특정 프로세스가 접근할 수 없는 영역을 침범하면 Segment fault 가 발생한다.
• Accounting Information
  : 프로세스와 관련된 자원 정보. CPU 사용, 실행된 시간 등
• I/O Status Information
  : 열어본 파일 목록, 프로세스에 할당 된 디바이스 정보 등 ...

PCB는 대략 테이블 혹은 해시 테이블 구조를 이용한다.

---

CPU Switch

 프로세스들은 일정 시간 간격으로 시분할 된 시간마다 Running 및 Ready 상태를 오고 간다. 이로 인해 프로세스들이 마치 동시간대에 실행되는 것 같은 효과가 발생한다. 

 특정 시간 간격이 지나면 현재 실행중인 프로세스는 자신의 정보를 PCB 에 저장하고 ( Save ) idle 상태가 된다. 다음 실행될 프로세스는 자신의 정보를 PCB로부터 컴퓨터로 가져와 ( Reload ) 실행된다. 해당 과정을 반복하면서 Context Switch 가 발생한다.

 이때, Context Switch는 Process 관련된 정보를 교환하는 작업이 존재하기 때문에 자체적으로 오버헤드가 된다. 만약 시분할이 적절하게 실행되지 않으면 오히려 안하는 것만 못한 결과가 나온다.

 하드웨어의 특성에 의존하는 경향이 있다. CPU가 여러개이거나 레지스터 셋 자체가 여러개인 경우, 동시에 여러 context을 로드하거나 실행할 수도 있다고 한다.

프로세스와 스레드

 하나의 프로그램을 구성하기 위해 멀티 프로세싱 및 IPC(Inter Process Communication) 을 이용하기도 하는데, IPC에는 자원이 들기 때문에 성능이 다소 떨어지는 경향이 있다. 또한 다양한 연산이나 I/O 에 의해 대기시간이 생겨, 프로세스들이 최선의 성능을 내지 못하는 경우도 발생한다.

  어차피 프로세스 간 통신을 통해 하나의 작업을 수행할 것이라면, 차라리 하나의 프로세스 내에 여러개의 흐름을 만들어 동작하게 하는 것은 어떨까? 이 경우 IPC을 이용하지 않고도 전역 변수를 통해 자원을 공유할 수도 있을 것이다.

 스레드는 위와 같은 배경에서 고안되었다. 스레드는 프로세스 내의 여러개의 실행 흐름을 의미한다. 각각의 스레드는 자신의 Program Counter을 가지고 있으며, 개별 스레드의 정보와 관련된 영역 이외에 스레드 간 공유 가능한 데이터 영역( 전역 변수 등 )이 존재하므로,  불필요한 메시징 또는 메모리 공유 없이 동작을 수행할 수 있다.

---

프로세스의 표현 방식

Linked-List 형태로 표현될 수도 있다.

프로세스 스케줄링

CPU에서 다음에 실행할 프로세스를 선택하는 작업을 프로세스 스케줄링이라고 한다. CPU의 최대 효율을 위해 수행하며, 스케줄링을 위한 큐가 여러개 존재할 수도 있다. 일반적으로 Ready -> Running 을 정하는 것을 의미한다.

• Job Queue : Long Term Scheduler
  : Ready 상태에 들어가기 위해 대기중인 New 상태의 프로세스들이 존재하는 큐.
• Ready Queue
  : 실행을 대기중인 프로세스들이 존재하는 큐.
• Waiting Queue
   : 이벤트를 대기하고 있는 프로세스들이 존재하는 큐.

• Long Term Scheduler ( Job Scheduler )
  : 어떤 프로세스를 Ready Queue로 옮길지 결정하는 스케줄러. 기본적으로 컴퓨터가 동시에 수용할 수 있는 프로세스의 수는 정해져 있기 때문에 ( degree of multiprogramming ), 해당 스케줄링이 필요하다.
• Short Term Scheduler ( CPU scheduler )
  : 어떤 프로세스가 다음에 실행될지 결정하는 스케줄러. ms 단위로 자주 동작한다 ( context switch )
• Mid Term Scheduler
  : 현재 Running 상태에 있는 프로세스들이 있을 때 우선도가 높은 작업이 들어와야 할때, 상대적으로 우선순위가 낮은 프로세스를 메모리에서 디스크 상으로 저장하고, 고 우선도 프로세스를 메모리에 적재하기 위한 스케줄러. 보통 언급한 동작을 "스와핑" 이라고 하는데, Mid Term Scheduler은 스와핑에 사용되는 스케줄러이다.

• I/O bound process
  : CPU 계산보다 I/O 작업에 시간을 더 많이 할당하는 프로세스
• CPU bound process
  : CPU 계산에 더 많은 시간을 할당하는 프로세스

프로세스의 특성에 따라 적절한 스케줄러를 사용하는 것이 중요하다.

---

프로세스의 생성

 프로세스의 부모 프로세스가 자식 프로세스를 만드는 방식으로 생성된다. 따라서 전체 프로세스는 일종의 트리 자료구조의 형태로 연결되어 나타난다. 

• fork : 부모의 현재 실행환경을 복사하여 자식 프로세스를 생성하는 시스템 콜. 자식 프로세스의 pid 반환
• exec : 현재 실행중인 환경 정보를 새로운 프로그램으로 대체하는 시스템 콜

 모든 프로세스들은 서로 식별하기 위한 번호인 process identifier (pid) 을 가진다. 이때 부모 프로세스의 pid는 항상 자식 프로세스보다 먼저 생성되므로, 자식 프로세스의 pid 보다 더 작은 값을 가진다는 특징이 있다.

 자식 프로세스는 부모 프로세스에 대한 자식 노드가 되므로, 이러한 프로세스간 데이터 공유 방식도 중요하다.

• 리소스 공유 방식
  • 자식 프로세스가 부모의 모든 리소스를 공유
  • 자식은 부모 프로세스의 일부 리소스를 공유
  • 부모와 자식은 어떤 리소스도 공유하지 않음
• 실행에 대한 옵션
  • 부모와 자식을 Concurrently 하게 ( 동시간대에 ) 실행
  • 부모는 자식이 끝날 때까지 대기

프로세스 트리.

0이면 자식, 양수면 부모. pid는 자식 프로세스의 pid

프로세스의 종료 ( Termination )

프로세스의 종료는 exit, abort 가 존재한다.

 부모 프로세스가 죽기 전에 자식 프로세스가 죽는 경우, 기본적으로 부모 프로세스와 자식 프로세스는 동일한 환경 정보를 기반으로 생성되었기 때문에 부모가 자식의 리소스에 대한 할당 관리를 수행할 수 있다.

 반대로 자식 프로세스보다 부모 프로세스가 먼저 죽으면, 자식은 일시적으로 orphan(고아) 프로세스가 되었다가 부모 프로세스보다 상위에 있는 프로세스의 자식으로 병합된다. 이때 부모 프로세스의 자원은 자식 프로세스에게 넘겨진다.

 자식 프로세스의 종료를 부모 프로세스에서 wait을 통해 대기하지 않는 경우, 부모 프로세스는 자식 프로세스의 종료 여부를 알 수 없기 때문에 자식에게 할당된 PCB을 해제할 수 없다. 이처럼 프로세스는 이미 죽었지만, 부모가 해당 사실을 알지 못해 PCB 정보만 계속 남아 있는 경우를 zombie 프로세스라고 하며, 해당 프로세스는 이미 죽었으므로 kill로도 죽일 수 없다. 최선의 방법은 부모 프로세스를 죽이는 것이다.

exit()

 앞서 프로그램과 프로세스의 차이는 메모리 적재 및 환경에 있다고 설명했다. 프로세스는 실행되기 위해 메모리 및 환경 정보를 가져야 한다. 따라서 프로세스가 종료될 때는 해당 정보들 역시 프로세스의 종료에 따라 정리되어야 한다.

 exit 시스템 콜은 프로세스를 종료할 때 사용되는 시스템 콜로, 할당되었던 각종 리소스들을 할당 해제하는 clean up 동작을 포함하고 있다. exit을 통해 프로세스가 종료되면, 부모가 wait을 통해 자식의 종료를 대기하고 있는 경우, 부모 프로세스에게 자식과 관련된 각종 정보를 전달한다.

abort()

 항상 모든 프로세스가 정상적으로 종료될 수 있는 것은 아니다. 예를 들어, 흔히 우리가 프로그램에 "렉"이 걸렸다고 표현하는 상황을 생각해보자. 어떤 프로그램이 렉걸려서 쉽게 종료되지 않는 경우, 우리는 작업관리자를 켜서 해당 프로그램을 "강제 종료" 하고는 한다. 이 경우, 해당 프로세스는 clean up 하지 못하고 비정상적으로 종료된다.

 abort 시스템 콜은 프로세스를 강제적으로 종료해야 할 때 사용되는 시스템 콜로, 할당되었던 리소스와는 관계 없이 프로세스 자체만을 종료한다. 이 경우 할당 해제되지 않은 정보는 운영체제의 재량에 맡기게 된다.

• 자식 프로세스가 할당된 자원 이외의 영역을 침범하는 경우
• 자식에게 배정된 task가 더 이상 필요하지 않는 경우
• 부모가 종료되었을 때, 운영체제가 자식의 지속을 허용하지 않는 경우 ( cascading termination )

---

멀티프로세스 아키텍처

하나의 프로그램을 여러개의 프로세스로 구동하는 방식을 멀티 프로세스 아키텍처라고 한다.

 

 웹 브라우저는 멀티프로세스 아키텍처의 대표적인 예시이다. 현재 구글 크롬과 같은 브라우저는 각 탭을 나눌 수 있다. 각각의 탭이 따로 존재할 수 있는 이유는 하나의 프로그램에 대해 각각의 탭이 일종의 프로세스로 동작하기 때문이다.

 하나의 탭을 구성하기 위해서는 UI / Browser / Plug-in 관련 프로세스가 필요한데, 현재 나는 탭을 3개 켜고 있으므로 프로세스의 수가 얼추 맞아 떨어진다.

 과거에는 탭과 비슷한 기능이 하나의 프로세스로 구성되어 있었기 때문에 만약 하나의 탭에 문제가 생겨 작업관리자를 통해 종료하면 다른 탭들도 함께 종료되는 불상사가 있었다. 그러나 현재는 각각이 독립된 프로세스이므로, 하나의 프로세스에 문제가 생기더라도 다른 프로세스들은 영향을 받지 않는다.

---

IPC ( Inter Process Communication ) 

 시스템 내의 프로세스들은 독립적으로(independent) 동작할 수도 있지만, 다른 프로세스와의 통신을 통해 협력할 수도(cooperating) 할 수도 있다. 이때, 각각의 프로세스는 자신이 접근할 수 있는 메모리 영역에 제한을 가지고 있으므로 함부로 다른 프로세스의 정보를 읽어오거나 메모리 영역을 침범하는 것이 불가능하다.

 프로세스의 협업은 다음과 같은 이유로 필요할 수 있다.

• Information Sharing
  : 특정 프로세스가 가지고 있는 정보를 다른 프로세스와 공유한다.
• Computation speedup
  : 다수의 프로세스를 병렬적으로 처리하여 컴퓨팅 속도를 높인다.
• Modularity
  : 하나의 프로그램 내에서 다양한 기능을 개별적으로 동작할 수 있도록 만든다.
• Convenience
  : 싱글 프로세스로는 처리할 수 없는 일을 처리한다.

위와 같은 이유로 등장한, 프로세스 사이에서 통신하기 위한 기술을 IPC 라고 한다. IPC에는 크게 두가지 방식이 있다.

• Shared Memory
• Message Passing

공유 메모리 방식(좌) 와 메세지 패싱 방식(우)

Producer-Consumer Problem

프로세스 간 통신에는 정보 공유에 있어 몇가지 문제가 존재할 수 있다.

• Producer : consumer이 소비할 정보를 계속 만드는 프로세스
• Consumer : Producer 이 생성하는 정보를 계속 받는 프로세스

 물건의 생산 및 소비가 1 : 1 비율로 계속 수행되면 이상적이지만, 대부분의 환경에서는 정보의 생산 속도와 소비 속도가 다르다. 따라서 다음과 같은 경우가 존재할 수 있다.

양측의 속도에 따라

• 생산 속도가 더 빠른 경우
  : 소비자가 소비해야 할 정보가 계속 쌓인다. 만약 소비자가 수용할 수 있는 최대치를 넘으면, 정보가 소실된다.
• 소비 속도가 더 빠른 경우
  : 생산자가 정보를 생성할 때까지 계속 대기하므로, CPU 자원이 낭비될 수 있다.

버퍼의 크기에 따라

• Unbounded-buffer
  : 생산자는 계속 정보를 만들고, 소비자는 계속 정보를 소비하게 된다. 이 경우 양측의 속도에 차이가 있더라도 큰 상관은 없다. 그런데, 현실에서는 컴퓨터의 물리적인 이유로 이런 상황이 사실상 불가능하다.
• Bounded-buffer
  : 생산자는 소비자의 버퍼 이상의 데이터를 만들 수 없다. 소비자는 버퍼가 비어있는 경우 무기한 대기한다.

---

Bounded-Buffer

 실제 컴퓨터에서는 물리적 이유로 Bounded-Buffer 방식을 채택한다. 

Shared Memory

 프로세스 간 커뮤니케이션을 할 수 있는 공유 메모리 공간을 만드는 방식으로, 연관된 두 프로세스에 대해 공유 메모리 공간을 생성한다. 프로세스 사이의 공간을 공유하면 되기 때문에 os의 개입 여지가 적다.

 공유 메모리는 원형 큐 자료구조를 이용한다.

공유 아이템 및 공유 메모리 정의

공유 데이터. 원형 큐이므로 최대 사이즈는 buffer_size - 1 이다.

 

생산자 프로세스

소비자 프로세스

---

Message Passing

 프로세스 사이에 공유 메모리를 두는 대신, 메시지라는 형태로 데이터를 가공하여 전달하는 방식. 프로세스 간 동기화 작업을 요구하므로, Shared memory 방식에 비해 다소 복잡하다. 

사용되는 메서드는 다음과 같다.

• send(message) : 데이터를 보낸다
• receive(message) : 메시지를 받는다.

 P와 Q라는 프로세스가 소통을 원하면 두 프로세스 사이에 communication link ( session ) 을 생성해야 한다. 이 과정이 완료된 후에야 양측 프로세스는 서로 메시지를 전달할 수 있다.

 Communication Link 을 만들 때 다음을 고려할 수 있다.

• Physical : 공유 메모리, 하드웨어 버스
• Logical : direct or indirect / synchronous or asynchronous / automatic or explicit buffering

구현 단계에서 고려할 점

• 링크는 어떻게 구성할 것인가? shared memory or bus?
• 두개의 프로세스 이상이 통신하는 경우는 어떻게 처리할 것인가? 링크 하나에 몇개의 프로세스를 연결할까?
• 각각의 프로세서 페어에 대해 몇개 까지의 링크를 허용할 것인가?
• 링크의 capacity는 어떻게 되는가?
• 링크의 데이터는 고정된 크기인가? 아니면 가변 길이인가? ( 프로토콜 관련 )
• 링크는 단방향인가, 양방향인가?

 Direct Communication

 프로세스 사이에서 직접 메시지를 전송하는 방식으로, send 및 receive 의 대상이 직접적으로 명시된다. 

• send(P, message) : P에게 메시지를 보낸다.
• receive(Q, message) : Q로부터 메시지를 받는다.

링크의 속성

• 메시지를 보내면 자동으로 연결된다. ( 구현에 따라 명시적으로 표현해야 할 수도 있음 )
• 링크는 정확히 한쌍의 프로세스에 대해서만 관계된다. ( 참여한 프로세스는 둘이 끝 )
• 한 쌍에 대해 정확히 하나의 링크만 생성된다. ( 하나만 있어도 되기 때문 )
• 링크는 단방향(unidirectional)일 수도 있으나, 보통 쌍방향(bi-directional)으로 구성된다.

Indirect Communication

통신에 참여하는 프로세스들이 메시지를 mailbox(port) 을 통해 주고받는 방식. 

• 메일박스 자체는 고유한 id가 존재한다.
• 프로세스들은 메일 박스를 공유할 수도 있다.

링크의 속성

• 링크는 메일박스를 통해 통신을 하는 경우 연결된다.
• 링크는 많은 프로세스에 관계될 수 있다. ( 메일박스는 공유가 가능 )
• 프로세스 쌍들은 많은 communication link을 가질 수 있다.
• 양방향 / 단방향 모두 가능.

수행하는 동작

• 메일박스 생성 ( 메일박스를 경유하여 통신을 진행한다)
• 메일박스를 통한 메시지 송신 및 수신한다.
• 메일박스를 다 사용한 이후, 삭제한다.
• send(A, message) : 메일박스 A에 메시지를 전달한다.
• receive(A, message) : 메일박스 A에서 메시지를 받는다.

문제점

 간접 통신 방식은 메일박스를 경유하여 메시지를 주고받는다. 이때, 메일박스 자체는 id가 있지만 메일박스를 사용하는 프로세스들을 구분하기 위한 방식은 정의되어 있지 않으므로, P와 Q 사이에 링크가 생성되더라도 반드시 P가 보낸 메시지가 Q에게 전달된다는 보장이 없고, 다른 프로세스가 보지 않는다는 보장도 없다. 만약 해당 메일박스를 P, Q 이외에 R 이 사용하고 있다면? P가 보낸 메시지를 R이 받거나, 살펴본다고 해도 구분할 수 없다.

해결책

정책상으로 어떻게 처리할 것인가에 따라 달라진다. 각 상황에 맞는 메일박스를 만들면 된다.

• 메일 박스를 한 쌍의 프로세스에 대해 각각 만든다. ( 이외의 프로세스가 사용 불가 )
• 먼저 받아 본 프로세스가 해당 메시지를 사용하도록 한다. ( 최대 1개 프로세스만 허용 )
• 시스템적으로 수신자 및 송신자 정보를 추가한다.

Synchronization

• Blocking ( synchronous, rendezvou ) 
  : 메시지 패싱이 동기화된다. 메시지를 주거나 받을 때까지 계속 대기하게 된다.
  
  • Blocking Send : 메시지가 도착할 때까지 기다린다.
  • Blocking Receive : 메시지를 받을 때까지 대기한다.

• Non-blocking ( asynchronous )
  : 메시지 패싱이 비동기적으로 처리된다. 메시지 관련 동작이 없을 때는 다른 동작을 한다.
  • Non-blocking Send : 메시지 보내는 동작을 계속 수행한다.
  • Non-blocking Receive : valid 한 메시지를 받거나, 텅 빈 메시지를 받는다. 계속 대기하지 않는다.

Buffering 

• Zero Capacity : 링크에 메시지를 위한 큐가 없는 경우. Blocking 방식에 해당한다.
• Bounded Capacity : 제한된 버퍼 범위 내에서만 수신 및 송신한다. 링크가 꽉 차면 멈춘다.
• Unbounded Capacity : 큐가 무한히 증가할 수 있어, 메시지를 계속 보내고 받는다.

---

Posix 환경에서의 IPC

공유 메모리 기반으로 동작한다.

Posix Producer

Posix Consumer

Mac / Windows 

메시지 패싱 방식을 이용한다.

---

Client-Server 모델

• 클라이언트 : 서비스를 요청하는 측
• 서버 : 서비스를 제공하는 측

Client-Server 방식 통신 

• Socket
• Remote Procedure Calls
• Pipes

---

소켓

 멀리 떨어진 호스트 사이에서의 통신을 위해 만들어진 일종의 api. IP/Port 정보로 Host/Process 을 찾는다. 라우터의 라우팅 규칙에 따라 패킷을 다른 방향으로 전달하는 과정을 거쳐 양측 프로세스 사이를 연결하게 된다.

RPC

 원격에 존재하는 프로시저(함수)를 실행하는 방식. Stubs 을 통해 서버, 서버의 함수 이름 및 파라미터 정보 등을 알아온 후, 데이터를 marshalling 을 통해 원격 서버의 정보 표현 방식 (리틀 인디안, 빅 인디안 ... ) 으로 변경하여 보낸다. 서버측에서는 해당 정보를 받아 함수를 실행하게 된다.

• 클라이언트가 RPC 보내기 시도
• 커널 측에서 실제로 상대방 있는지 검사
• 있으면 연결 시도 (포트넘버 전달)
• 클라이언트 측에서 서버로 RPC 통해 정보 전달
• 서버측에서 클라이언트 측으로 결과물 전달
• 클라이언트가 정보 받음.

Pipe

두 프로세스 사이에서 통신할 수 있도록 하는 통로이다. 

• 통신은 단방향 혹은 양방향?
• half or full-duplex?
• 프로세스 사이에 관계(부모 자식 등) 가 반드시 있어야 하나 ?
• 네트워크를 경유하나?

Ordinary Pipe

 producer-consumer 모델 형식의 전통적인 파이프 구조로, 한 프로세스는 다른 프로세스에 대해 읽기(read-end) 및 쓰기(write-end) 파이프를 가진다. 따라서 파이프 자체는 단방향이지만, 정보는 두 프로세스 사이에 서로 공유될 수 있다.

 부모 자식 관계의 경우, 부모가 파이프를 만든 후 fork를 하면 하나의 파이프를 자식과 공유할 수 있게 된다. 따라서 ordinary pipe는 부모 자식 관계를 요구한다.

window 운영체제에서는 anonymous pipe 라고 부른다.

Named Pipe

 파이프 자체에 이름을 붙이고, 서로 다른 프로세스 사이를 연결하는 방식. 쌍방향 통신을 지원하며, 부모 자식 관계가 강제되지 않는다. 다수의 프로세스들이 통신을 위해 사용할 수도 있다.