OS - (2) Processes

정선용·2022년 3월 31일

2.1 Process

프로세스란 ?

프로세스 : 프로그램의 인스턴스. 메모리공간에 적재(=실행)된 프로그램. 운영체제의 가장 기본적인 실행단위.

프로그램 vs 프로세스

프로세스는 메인 메모리에 할당되어 실행중인 상태인 프로그램.
프로세스는 실행하면서 stack pointer, data, text, register 등이 끊임없이 변한다. 프로세스는 job, task 등으로 불리기도 한다.

프로그램은 일반적으로 하드디스크(보조기억장치)에 저장되어 아무 일도 하지 않는 상태이다. 이진 바이너리 파일로 저장만 되어있는 상태.

프로세스 구조(메모리)

프로세스는 pid당(고유) 메모리 공간을 할당받고, 논리적으로 메모리가 형성되어있으며 각 영역 정보들이 물리적 공간에 할당된다.

stack : 정적 메모리 영역.
heap : 동적 메모리 영역
data : 전역 변수가 저장
text : 2진수 기계어로 번역된 코드가 text공간에 저장.
이 때 stack은 윗 공간에서 아래로 쌓아나가고, heap은 아래 공간에서 위로 쌓아나간다. (논리적으로, 물리적으로는 연속적 저장되지 않음)

프로세스 상태(state)

New : 새로운 프로세스 생성(folk) 자료구조는 생성되었지만, 메모리 획득을 받지 못한 상태
Running : CPU 할당되어 실행중인 상태 .
- running-> ready : cpu 스케줄링에 의해(한 프로세스가 CPU 독점하는 것 방지) preempted될 때 running에서 ready로 간다.
- running-> waiting : block. 프로세스가 허가된 시간을 다 쓰기 전 입출력 등 이벤트 동작을 필요로 하는 경우. (cpu를 스스로 반납하고 waiting)
Waiting : 프로세스가 이벤트를 기다리는 상태 (Blocked) : 다른 프로세스의 응답을 기다리거나, 느린 입출력을 기다리는 동안 다른 프로세스가 실행될 수 있도록 Waiting queue에서 이벤트를 기다린다.
- 프로세스가 끝나지 않은 시점에서 I/O로 인해 CPU를 사용하지 않고 다른 작업.(작업이 끝나면 다시 CPU에 의해 실행되기 위해 ready 상태로 돌아가야하고, 이는 I/O완료 등의 이벤트 발생에 의해 ready로 돌아가게 된다.)
  CPU를 할당 받아도 명령을 실행할 수 없는 상태
Ready : 프로세스가 실행되기 전 대기상태 : 스케줄링 프로세스에서 Ready Queue에 위치한다. dispatcher에 의해 dispatch(scheduled)되면 ready queue 맨 앞 프로세스가 CPU를 점하며 running상태가 된다. CPU할당 X 상태 . CPU만 보유하면 명령 실행 가능한 상태.
Terminate : 프로세스가 실행을 마친 상태. (정상종료 / zombie state도 포함.), 종료 후 아직 자료구조를 완전히 정리하진 않은상태.

Process Control Block(PCB)

PCB : 운영체제가 각 프로세스 관리,유지를 위해 가지고있는(커널 내) 자료구조이다. (OS는 프로세스마다 PCB를 하나씩 두고 관리함 : 프로세스당 하나의 PCB )
프로세스가 생성되면(new) pcb라는 자료구조가 kernel영역에 생긴다. pcb는 프로세스 중요 정보를 포함하므로 user가 접근 불가하도록 보호된 메모리 영역에 존재. 일부 운영체제에서는 pcb는 커널 스택의 처음에 위치하기도함(편리 및 보호)
PCB는 프로세스 당 연관 정보들을 가지고있다.
어떤 값들을 가지고있는지
- process 상태 (new/ready/running/wait 등)
- Program Counter : 다음 실행할 프로세스(명령어) 주소
- CPU reisters : 연산 결과를 일시적으로 저장하는 레지스터(accumulator)(논리수리,주소계산,메모리포인터,범용레지스터,스택레지스터 등)
- CPU 스케줄링 정보 : 프로세스 priority, 큐에 대한 포인터 등(스케줄링 파라미터)
- memory 관리 정보 : code,data,stack 위치정보, page table, segment table . .
- accounting정보 : cpu점유시간, (process number: PID), 부모 등
- I/O정보 : 해당 프로세스에 할당된 IO장치, 열어본 파일목록 등
  
  주요 존재 목적 : intterupt 발생 시 문맥 저장 및 프로세스 생명유지. CPU는 한 프로세스가 종료될 때 까지 수행하는 것이 아닌 여러 프로세스를 중간중간 바꿔가며 수행하는데, 이 때 PCB에 값들을 저장하기 때문에 중간에 끊겨도 저장된 값을 참조해 이어서 수행할 수 있음.

2.2 Process Scheduling

Context Switching

멀티프로그래밍
단일 프로세서(CPU) 환경에서 여러 개 프로세스가 동시에 실행되는 것.(실제 동시 X, 병렬 O)
멀티 프로그래밍은 하나의 프로세서가 하나의 프로세스를 수행하는 동안 다른 프로세스에 접근할 수 있도록 하는 방법.
Degree of multiprogramming
멀티프로그래밍의 정도는 현재 메모리에 할당되어있는 프로세스 개수를 말한다.
context-switching
: 하나의 Process / Thread에서 다른 Process/Thread로의 CPU점유 전환.
cpu는 동시에 프로세스를 처리하지 못하고 병렬적으로 여러 프로세스들(멀티프로세스) 처리하는 것이며, 여러 프로세스들을 번갈아가며(바꿔주며) 처리를 진행해 나간다. 이 때 발생하는 것이 context switching.
프로세스가 실행되다 인터럽트 발생(IO이벤트 혹은 timeout등)으로 os가 개입하여 cpu(프로세서)에 할당된 프로세스를 바꾸는 context switching이 일어나는데,
context switching 발생마다 dispatcher에서 overhead가 존재한다. (pcb나 task control block에 상태값들을 백업하고, 복구하므로.) : sw적으로는 효율적인 스케줄링이 필요하다.
context switching 빠르게 하는 법
- 하드웨어 가속 : 많은 레지스터 세트를 사용하거나 포인터연산을 가속화, TLB(Translation Lookaside Buffers)를 사용
- 소프트웨어가속 : 적절한 스케줄링 알고리즘을 통해 Context Switch와 프로세스를 조율
dispatcher : 스케줄링에서 CPU를 다른 process에게 넘겨주는 역할. pcb에 상태값들을 백업하고, scheduler가 선택한 다음 process를 읽어오는 역할. dispatcher 호출을 위해서는 interrupt 발생이 요구됨.

Job Scheduler

scheduler : cpu scheduler - cpu 할당을 위해 프로세스를 선택하는 역할을 하는 운영체제의 컴포넌트(구성요소).
- 장기 스케줄러: job scheduler. 디스크(풀)에 대기중인 프로세스들 중에서 ready queue로 옮겨질 프로세스들을 선택한다. 작업을 적절하게 골라준다. 이 때 ready queue에 옮겨진다는 것은 메모리에 로드된다는 것을 의미.
  - 호출 빈도가 낮아 느려도 괜찮으며, 메모리 상주 프로세스 개수를 제어한다.
  - context switching 오버헤드가 단기스케줄러에 비해 크다.
- 단기 스케줄러 : cpu scheduler, ready queue에 다음 cpu 실행될 프로세스를 선택. CPU가 할당된다.
  - cpu를 위해 자주 새로운 프로세스를 선택해야 해 호출빈도 높으며 빨라야한다.
- 중기 스케줄러(medium-term-scheduler) : 운영체제 실행동안 주기적으로 메인 메모리에 있는 전체 프로세스를 검사하여 보조기억장치로 옮길 프로세스를 옮기는 스케줄러. 중간정도 빈도이며 옮기는 기준은 여러 기준이 있고 장기간 사용하지 않는 프로세스가 대표적.
  - swapping : 메인 메모리에서 장기간 사용하지 않는 프로세스를 하드디스크(swap device)로 옮겨주고(swap-out) 나중에 프로세스가 다시 사용되려고 하면 하드디스크에서 해당 프로세스를 다시 메인메모리에 할당(swap-in). 이 때 swap-in으로 다시 메모리 할당 시 이전의 공간으로 할당되는 것은 보장하지 않음.
I/O bound process , CPU bound process
프로세스는 I/O bound와 CPU bound로 나뉜다.
- I/O bound process : 해당 프로세스에서 입출력(I/O)작업 비중이 높음.
- CPU bound process : CPU(계산) 작업이 차지하는 비중이 높은 프로세스.
  운영체제의 job scheduler는 IO, CPU bound process를 적절히 분배해 메모리 할당해주어야함.
  IO burst/ CPU burst의 조합을 적절하게 고려해주는 것은 job을 고르는 장기 스케줄러가 선별해야한다.
  하지만 현대 대부분의 운영체제는 장기 스케줄러를 잘 사용하지 않는다. 그 이유는 가상메모리의 존재 때문.
  가상 메모리의 목적은 한정된 메모리에 모든 프로세스들을 올려둘 수 없어 해결하고자 탄생했다.
  디스크(풀) 대기중인 새로운 프로세스들 중 ready queue로 옮겨주는 것이 장기스케줄러의 목적인데,
  메모리 문제는 가상메모리가 해결해줘 메모리에 어떤 작업을 올릴지 머리 싸맬 필요가 없어졌기 때문.
  그래서 스케줄러는 CPU(단기)스케줄러를 일반적으로 명칭하게됨.
  모든 새로운 프로세스는 단기 스케줄러에 의해 가상 메모리에 적재된다.
  중기 스케줄러도 메모리에 올라와있는 프로세스들이 너무 많아 cpu가 감당할 수 없을 때 보조기업장치로 swap-out, 멀티프로그래밍 정도를 줄이는 역할인데, 가상메모리가 있어 현재 잘 사용하진 않는다.

프로세스 큐

프로세스가 순서를 대기하는 곳.
프로세스는 수행하면서 상태가 여러 번 변하는데 이에 따라 서비스를 받아야하는 곳이 다르고.(new-ready-waiting-running-terminated), 프로세스는 일반적으로 시분할되어 context switching이 자주 일어나므로 process queue에 적재된 순번대로 진행되게 된다.

job queue : 하드디스크에 있는 프로그램이 실행되기 위해 메인 메모리의 할당 순서를 기다리는 큐(실행할 프로세스들의 pcb 모임)
ready queue : CPU 점유 순서를 기다리는 큐(실행을 위해 메모리가 할당된 프로세스들의 pcb모임)
device queue : I/O를 하기위한 디바이스들마다 존재, 각 장치를 기다리는 큐. = waiting queue. (자원을 사용중이거나, 사용하기 위해 기다리는 프로세스들.=waiting)

프로세스 상태 기준으로 생각해보면 프로세스 new상태는 job queue에 있는 상태, 메모리에 할당되어 ready queue에 있는 상태가 ready, running상태는 cpu를 할당받아 실행중인상태, running상태에서 I/O의 interrupt가 발생하게되면 blocked되어 I/O 작업 수행을 위해 장치를 기다리며 I/O queue에 있는 상태(CPU반환)가 wait상태.

2.3 Operating on Process

Process creation

process는 tree 구조를 갖는다. 생성자 프로세스를 부모로, 생성된 프로세스를 자식으로 하는 tree. pcb에도 부모 정보를 저장한다. (pid값으로 식별)
컴퓨터 부팅 시 init process가 루트 프로세스로, 다양한 user process들을 생성하는 것.
부모 프로세스는 자식에게 자원을 분할하거나 공유할 수 있음. (cpu,메모리,io디바이스등.)

2가지 프로세스가 child 생성 시 방법
- 부모 프로세스와 자식 프로세스가 동시에 실행( 멑티 프로세싱 환경 )
- 부모 프로세스는 자식 프로세스가 종료될때까지 기다리는 방식 (:wating queue)
2가지 메모리 로딩방식
- 자식 프로세스가 새로운 메모리 공간에 load
  - 프로세스 load : executable file path를 os에 전달, memory context의 code segment로, 전역변수 선언,정보들을 data segment에 읽어들이고 빈 stack, heap을생성함. load 이후 프로세스 정보 담은 pcb를 동적할당하여 내용을 채우고, pcb를 ready queue에 넣는 것.
- 자식 프로세스는 부모 프로세스의 메모리 공간을 복제하는 경우. 이때 자식 프로세스와 부모 프로세스는 동일
  - fork(unix계열) : 부모 프로세스와 pid만 다르고 나머지는 동일한 child process가 생성되는 system call. unix계열은 0번 프로세스만 load방식으로 생성하고 나머지는 복제(fork)를 이용.
process 생성 주기
- fork
  새로운 자식 프로세스를 생성하는 시스템 콜 함수.
  부모의 리소스와 동일(pid,메모리주소 제외)한 프로세스를 생성.
  자식에게 부모의 프로그램,데이터가 완전 복사된다. 이 때 부모프로세스에서 자식의 pid(pid>0)을 반환하고, 자식 프로세스에서는 0을 반환하며, 반환값으로 부모프로세스, 자식프로세스를구분.
  
  동일하다는 것은
- exec
  프로세스를 새로운 프로그램을 실행하는 프로세스로 대체하는 시스템 콜 함수.
  fork()와 다르게 자식 자식 프로세스를 생성하는 것이 아닌 현재 프로세스의 프로그램 코드를 새로운 프로그램 코드로 바꿔주고 프로그램 코드, 메모리, 파일 등 프로세스 자원이 새로 바뀌게 됨.( 새로운 프로그램 실행 프로세스로 대체되므로 반환값 x
  보통 동작하는 방식은 fork()를 통해 자식 프로세스를 생성하고 자식 프로세스에서 exec()를 통해 새로운 프로그램을 돌리게 된다.
- wait
  자식 프로세스가 종료될 때까지 현재 프로세스의 동작을 멈추는 시스템 콜 함수
  자식 프로세스가 종료되면 자식 프로세스 종료 시그널이 발생하여 waiting queue에 있는 부모 프로세스가 ready queue로 넘어가게 되어 다시 실행이 가능해짐.
- exit
  현재 프로세스가 종료되어 시그널이 부모 프로세스로 전달되고, wait() 된 부모 프로세스는 자식 프로세스의 exit() 함수에 의해 정상 종료(자원 해제..)가 됨을 알 수 있음. (return키워드는 exit()를 호출한다) : 자발적 종료

Process termination

프로세스의 종료
프로세스의 종료(exit)는 프로세스가 가지고있던 자료구조나 자원들을 OS가 회수함을 의미. 회수 이후에는 부모 process에게 시그널이 가게되고 부모 process는 자식이 정상 종료 됨을 알고 수행을 재개할 수 있다.
- exit() 시스템콜 - 프로세스 종료 및 정수인자 반환. 부모 프로세스는 wait()시스템콜을 통해 상태를 반환받는다. 이 때, exit를 끝마친 process를 zombie process라 하며, exit를 마치고 부모 process가 자신의 exit status를 읽어가기를 기다리는 상태를 zombie state라고 함.
프로세스 종료 시키는 이유
- 자연종료
- 자식 프로세스가 너무 많은 자원을 사용하는 경우
- 자식 프로세스의 동작 결과가 어떤 이유로 인하여 더 이상 필요 없을 경우
- 부모 프로세스가 동작을 마치고 종료하는 경우
고아프로세스(orphans)
: 자식 프로세스가 작업중인데도 부모 프로세스가 먼저 종료되어버린 상황. (부모가 wait 하지 않고 종료. ) -> 부모는 fork를 통해 자식 프로세스의 pid값을 반환한다. 그러나 자식 pid를 반환하기도 전에 부모프로세스가 죽어버리면 : 자식 프로세스는 부모 프로세스의 pid를 가져올 수 없게 된다. 그렇기 때문에 부모에서 wait을 통해 이를 방지해줘야 한다. (자신의 일이 끝나도 자식의 반환값을 기다린다.)
고아 프로세스의 경우 직계 부모 프로세스를 찾을 수 없어 부모 프로세스 호출(get ppid) 시 init process(root)의 pid == 1을 반환하게됨.
-> 운영체제에서는 고아 프로세스를 허용하지 않으므로 부모 프로세스가 먼저 종료되면 init(pid 1)이 부모로 설정된다.
고아 프로세스는 프로세스 자신이 시스템 자원을 낭비할 수 있고 시스템이 프로세스가 종료될 때 까지 추적을 해야하기 때문에 성능 저하의 원인이 됨.
결론적으로는 init 프로세스가 고아 프로세스의 부모로 관리해주지만 성능 저하 방지를 위해 부모 프로세스가 종료되기 전에 wait해 자식의 종료를 기다려주는게 좋다.
좀비 프로세스(zombie)
자식 프로세스가 종료되었지만 부모 프로세스에게 pid를 반환시켜주지 않아 자식프로세스의 state값을 회수하지 못한 프로세스. (부모가 wait을 아직 호출하지 않은 상태에서 자식이 종료.)
자식이 부모보다 먼저 종료되는 경우 부모 프로세스가 종료 상태를 회수하기 위해 커널이 자식 프로세스의 최소한의 정보(PID,상태,커널에서사용하는 구조체등)을 남겨두는데,
부모 프로세스는 자식 프로세스의 termination state 를 반환받아야 커널에서 자식 프로세스의 정보를 가지고 있는 구조체를 해제 시킬 수 있다. 이 때 부모가 wait 함수를 호출하지 않아 exit status를 회수하지 못해 zombie처럼 종료했지만 종료하지 못한 상태인 프로세스로 남아있는다. (defunct)
zombie 프로세스는 최소한의 정보만을 가지고있어 큰 성능저하를 야기하지는 않지만 운영체제는 한정된 PID를 가지고 있으므로 좀비 프로세스가 PID를 차지, 프로세스 스케줄링 입장에서는 queue에 걸려있는 프로세스 양이 증가하고 커널 구조체를 유지하기 위한 비용 또한 존재.
- 좀비 프로세스 관리법
  (1) wait : 부모 프로세스에서 wait 함수 호출.
  (2) signal, wait : wait함수는 블록 모드로 동작하는 함수이므로 부모 프로세스는 wait함수를 호출한 즉시 동작을 멈춤. 이를 방지하기 위해 시그널 도구를 활용하여 자식 프로세스가 종료되는 경우 발생하는 SIGCHILD 시그널에 해당하는 핸들러를 만들고 해당 핸들러에서 wait함수를 호출하면 됨.

kill
linux명령어 kill과 유사한 시스템콜 kill() 함수는 프로세스에게 특정 시그널을 전송하며 SIGKILL 시그널을 보내게 되면 명령어 kill과 같은 동작을 함.
- pid인수에 따른 동작
  양의 정수 : 해당 PID 프로세스에 시그널
  0 : 같은 프로세스 그룹에 있는 모든 프로세스에 시그널
  -1 : 프로세스 전송 권한이 있는 모든 프로세스에 시그널
  -1외 음수 : 절대값 취한 수의 프로세스 속한 모든 그룹에 포함된 모든 프로세스에 시그널
abort()
부모 프로세스가 자식 프로세스를 강제종료시킴.

2.4 InterProcess Communication

Cooperating process

IPC

cooperating process : 협력프로세스, 다른 프로세스에 영향을 미치거나 받을 수 있는 프로세스
independent process : 독립 프로세스, 실행 중인 다른 프로세스에 영향을 받을 수 없는 경우.
협럭 프로세스 사용 이유
동일한 정보에 접근할 수 있는 환경 제공, 성능적인 측면에서 이득. (특정 작업을 병렬적으로 다른프로세스와 함께 실행), 시스템을 모듈형식으로 만들기 위해. 다수 프로세스들이 협력, 한 번에 하나의 일을 하는 것이 아닌 다수의 일을 하게될 때(멀티태스킹)
-> 마이크로 커널, 나노 커널 등 프로세스간 통신이 많이 일어나는 경우 IPC방식에 따라 성능이 좌우될 수 있다.
IPC
프로세스들 간 의사소통하는 것. 데이터를 주고받는 방법. 정보를 주고받기 위한 통신의 일종. (마치 server-client 통신처럼 process들간 통신.)
프로세스가 서로 데이터를 주고 받는 방법, 경로. 프로세스 communication 모델은 크게 2가지가 있다. (shared memory, message passing) 이 외에는 파일을 통한 통신, signal을 통한 통신, 세마포어 등이 있다.

IPC - shared memory

두 프로세스가 동일한 데이터 공간을 공유하는 기법.

system call을 통해 주소 공간을 일부 공유하고, 동일한 물리적 메모리에 매핑한다.
생산자-소비자(producer-consumer)모델과 유사하다.(생성자 프로세스가 전송할 내용 명령등을 공유공간에 다마두고 다른 프로세스들이 받아서 작업하는 구조)

동작 과정
- 공유 메모리를 사용할 프로세스들 중 하나의 프로세스가 자신의 부여받은 메모리 영역 중 일부 선택
- 다른 프로세스들은 공유할 메모리의 주소를 받아 자신의 메모리 영역에 붙임(attach 방식).
- OS가 개입해 해당 프로세스들 간 메모리 접근제한 풀어줌.
- 이후 프로세스들은 공유 된 메모리(shared memory)를 통해 통신하게된다.
  OS의 권한 필요 : 일부 영역의 메모리를 여러 프로세스가 동시에 접근할 수 있도록 OS로부터 권한을 받는데, 처음 메모리에 여러 프로세스가 접근 권한을 부여하는 작업에서만 커널 작업이 필요하고 이후에는 커널 동작이 필요 없음.
장점/ 단점
- 장점
  대량의 정보를 다수의 프로세스에게 바로 배포 가능.
  중개자 없이 곧바로 메모리에 접근할 수 있기 때문에 모든 IPC 중에서 가장 빠르게 작동.
- 단점
  동기화 문제로 관리가 어렵다
  - 참고 ) PRODUCER-CONSUMER 동기화 문제
    - 공유 메모리 버퍼 형태
      - unbounded buffer : 메모리 버퍼 크기에 제한이 없다. consumer는 새 자원이 만들어질 때 까지 기다려야하고 producer는 항상 새로운 자원을 만들 수 있음.
      - bounded buffer : 메모리 버퍼 크기에 제한이 있으며 consumer는 버퍼가 빈 상황이면 새로운 자원이 채워질 때 까지 기다리며 producer 프로세스는 버퍼가 꽉 차있으면 공간이 남을 때 까지 기다려야 한다.

IPC - shared memory - Memory Map

공유 메모리처럼 메모리를 공유. 메모리 맵은 열린 파일을 메모리에 매핑시켜 공유하는 방식이며, 공유 매개체가 파일+메모리이다.
주로 파일로 대용량 데이터를 공유해야할 때 사용.
대부분 운영체제에서는 process 실행 시 실행파일 각 segment를 메모리에 매핑하기 위해 메모리 맵 파일을 이용한다.

IPC - Message Passing

kernel에게 메세지를 보내면 kernel이 알아서 처리해주는 기법. 이 때 메세지는 데이터를 하나의 메세지로 취급해 프로세스간 통신을 하게된다.
communication link를 생성해 커널에 시스템콜(send, receive)를 요청하는 방식으로 구현된다.
메세지 큐를 사용하며 커널단에서 메세지 큐를 관리한다.

장점/ 단점
- 장점
  충돌의 위험이 없어 소량 데이터 전송에 유리. shared memory기법보다 구현이 쉽다. 같은 환경에 있지 않아도 internet을 통해 메세지를 주고받을 수 있음(소켓)
- 단점
  메세지 전송 시 system call이 발생하므로 성능상 느리다
메세지 패싱방식 프로세스간 통신 채널 : communication link와 send/receive연산
- 메세지 통신 대상 (직접/간접) :Direct / Indirect 에 따라 논리적 구현이 다르다.
  직접/간접통신.
  - 직접 통신의 경우 send() , recieve()를 통해 이루어지며, 직접 해당 프로세스로 메세지를 보낸다. 이 때 communication link는 두 프로세스 사이 자동으로 연결된다.
  - 간접 통신의 경우 mailbox, port로 메세지들이 송신, 수신된다. 두 프로세스들이 공유 메일박스(버퍼) 가질 때만 구축됨. 직접통신은 link가 1:1이었지만 간접통신시에는 여러 프로세스가 연관될 수 있음. (프로세스들 가운데 하나의 시스템/네트워크 등을 두고 메세지를 중재하며 동작, 유연하며 중재 시스템의 구현에 따라 보안성,성능 등 다양한 처리가 가능해진다)
- 메세지 전달 방식 동기화 : Synchronous(동기) / Asynchronous(비동기) 에 따라 논리적 구현이 다르다.
  메세지 전달 시 blocking , nonblocking 방식이 존재한다.
  - blocking send : send프로세스는 메세지가 수신될 때 까지 block된다.
  - nonblocking send : send프로세스는 메세지를 보내고 자신의 작업을 이어간다
  - blocking receive : 메세지가 available할 때 까지 receive 프로세스는 block.
  - nonblocking receive : send 프로세스는 메세지를 보내고 반환값을 반환받는다(메세지/null) - 메세지를 바드면 해당 메세지가 유효한 내용인지 검사하고 처리한다.
- 메세지를 보관하는 곳(큐) : Automatic / expliit buffering 에 따라 논리적 구현이 다르다.
  direct/indirect모두 우선 송수신되는 메세지는 임시큐에 존재한다.(indirect는 mailbox와같은 중개 큐가 존재)
  - buffering zero capacity : 큐의 크기 0. 대기 메세지 가질 수 없고 sender가 receive가 메세지 수신까지 무조건 기다려야한다.
  - bounded capacity : 큐의크기 제한적 : 큐가 가득차면 센더는 반드시 block
  - ubbounded capacity : sender는 block되지 않음.

IPC - Message Passing - pipe

통신을 위해 메모리 공간(버퍼)를 생성하여 프로세스가 데이터를 주고받게끔한다. messaging passing방법의 일종이라 할 수 있음.

익명 파이프
일반적인 파이프이며, 통신할 프로세스가 명확한 경우 사용. 기본적으로는 부모자식or형제 프로세스간 통신을 위해 사용 :외부 프로세스에서 사용 불가. (Direct)
파이프는 두 개의 프로세스를 연결하는데, 하나는 데이터 쓰기만, 하나는 데이터 읽기만 가능. (한쪽방향 통신만 가능하다) -> 양방향 통신 하려면 두 개의 파이프를 만들어야함. 간단하게 사용 가능하며 pipe함수로 생성가능
- 단점 : 반이중통신 -> 프로세스 read write 모두 해야한다면 pipe2개 구성으로 구현 복잡할 수 있고 낭비가 심할 수 있음
named 파이프
전혀 모르는 상태의 프로세스들 사이 통신에 사용.
프로세스 통신을 위해 이름이 있는 '파일'을 사용한다. : FD,파일 디스크립터
FIFO라 불리는 특수파일을 이용해 모르는 사이 프로세스들 간 통신 가능. (외부 프로세스와 통신 가능.) mkfifo/mknod함수로 생성.
- 단점 : 이역시 익명파이프 확장으로 반이중통신. 같은 컴퓨터 환경에서만 동작이 가능함.

IPC - Message Passing - socket

네트워크 소켓 통신을 통해 데이터를 공유한다.
socket이라는 구조를 만들어 통신하는데, 흔히 네트워크 통신 기법으로 많이 사용된다.

socket
데이터 교환을 위해 양쪽 프로세스(pc)에서 각각 임의의 포트를 정하고, 해당 포트간의 communication을 통해 데이터를 주고받는 방식.
소켓은 하나의 프로세스이다.(소켓은 임의의 port를 맡아 데이터 송수신하는 역할을 수행하는 프로세스.)
각 pc에서 소켓 프로세스를 통해 타 pc port에 연결하라는 명령을 보내면 두 프로세스는 서로 확인과정을 거쳐 연결을 진행하고 1:1로 데이터를 주고받는다.
단, 각 연결(둘이 연결되는 통로)은 1:1이지만, 한 프로세스가 1:1연결을 하나만 가져야하는 것은 아니다. 특성에 따라 1:N, N:M프로세스들이 짝이 될 수 있고 indirect방식으로 각 socket이라는 endpoint를 가지고 socket에 도달한 메세지를 읽어들이는 메세지 전달방식 인터페이스이다. : 정확히는 IPC 방식은 아니고 IPC를 구현하기 위한 하나의 인터페이스이며 설계에 따라 동기/동기방식 모두 사용가능(내부 프로세스간 통신 socket이용 가능)
보통 client-server가 소켓을 통해 통신하는 구조, 원격에서 프로세스간 데이터 공유 시 사용된다. (전이중:full-duplex).
서버는 bind,listen, accept를, 클라이언트는 connect를 사용한다(네트워크 망을 통해 연결을 bind하고, 포트를 listen하다가 메세지를 주고받고 함. : IP주소와 port 번호를 통해 소켓을 구분한다. )

IPC - Message Passing - 메세지 큐

메세지 패싱 가장 직관적 방법. 입출력은 named pipe와 동일하나,
메세지 큐는 파이프처럼 데이터의 흐름이 아니라 Memory 공간임.
또한 PIPE나 FIFO와 달리 다수 프로세스간 메세지를 전달할 수 있음.
사용할 데이터에 번호(식별자)를 붙이면서 여러 프로세스가 동시에 데이터를 쉽게 다룰 수 있음. 메세지 접근을 위해서는 이 식별자 (key)가 필요.

IPC - RPC(Remote procedure call)

RPC또한 프로세스간 통신을 위하 사용하는 IPC방법의 한종류이다.
분리된 PC(원격지)에 저장된 데이터를 자신의 PC에 존재하는 것 처럼 데이터(함수,프로시저 등 코드)를 가져와 사용 할 수 있는데, stub을 통해서 자신의 디스크에 존재하는 것 처럼 사용할 수 있다.

stub : linux 공유 라이브러리의 일부분 중 하나.

RPC는 제어 흐름이 특히 호출자와 수신자 간 교대로 이루어지는 client-serer(ex- 쿼리-응답) 상호작용에 적합하다. 개념적으로 동시에 실행되지 않고 실행 스레드가 호출자로부터 수신자에게 갔다가 응답을 가지고 돌아옴.

RPC의 궁극적 목표
client-server간 커뮤니케이션에 필요한 상세정보는 감추고, 일반 메소드를 호출하는 것 처럼 원격지의 프로시저를 간단하게 호출 가능하다. 메소드 또한 마찬가지.
RPC 동작방식
1. 클라이언트가 client stub procedure를 호출 (client stub는 클라이언트를 소유한 주소의 공간 내 위치)
2. client stub가 파라미터들을 표준 포맷으로 변경하고 각 파라미터들을 복사해 메세지로 넣는 등 메세지화한다.(wrapping)
3. client stub는 원격지(원격 서버 머신)으로 메세지를 보낸다(transport layer로)
4. 서버에서 transport layer는 메세지를 server stub로 보낸다. server stub는 메세지에서 파라미터들을 모아 프로시저 호출 메커니즘을 사용해 서버 루틴을 호출한다.
5. 서버 procedure가 완료되면 server stub로 반환되고, stub는 결과값들을 모아 메세지에 넣고 transport layer로 반환
6. transport layer - > client transport layer -> client stub 순으로 메세지 전송
7. client stub는 반환 파라미터들과 실행 결과들을 unpack해 자신의 머신에서 프로시저를 실행한 것 과 같은 결과를 얻을 수 있다.
요즘 RPC 자주 이용하는 이유
RPC 모델은 분산 컴퓨팅 환경에서 많이 사용됐으며, 현재는 MSA, 마이크로 서비스구조가 굉장히 많이 채택되고있다. 서로 다른 환경이지만 서비스간의 프로시저 호출을 가능하게 해줌에 따라 언어에 구애받지 않고 환경에 대한 확장이 가능하며, 좀 더 비즈니스 로직에 집중하여 생산성을 증가시킬 수 있는 RPC는 더욱 많이 사용되고있다.
장점
프로세스간 통신 비교적 쉽게구현, 네트워크 프로토콜에 신경쓰지 않고 개별 머신별 고유 프로세스에 집중 가능. (remote call코드가 간단하기때문)
단점
보안이 보장되지 않으면 호출 실행과 반환 시간이 보장되지 않음. (네트워크 구간 이용하는경우 네트워크 끊겼을 때 문제 발생)