[Operating System] Process (3)

dandb3·2023년 3월 7일

Operating System

Operating system

목록 보기

8/31

주의 : 굉장히 부정확할 수 있음.

Interprocess Communication

independent process :system에서 실행중인 어떠한 process와도 데이터를 공유하지 않는 프로세스
cooperating process : 시스템에서 실행되는 다른 프로세스에게 영향을 끼치거나 받을 수 있는 프로세스
process cooperation이 필요한 이유?
- Information sharing : 여러 application들이 같은 정보에 접근하고 싶어하는 경우가 있다. (복붙하는 경우)
- Computation speedup : 하나의 task를 여러 subtask로 나누어서 실행시키는데, 물론 당연히 서로 영향을 주고받을 것이다.
- Modularity : 하나의 system function을 여러 프로세스나 스레드로 나누어 module화 하기 쉽게 한다..?

Cooperating processes는 interprocess communication (IPC)를 필요로 한다.

IPC의 종류
- shared memory : 메모리의 특정 영역이 공유영역으로 설정되고, 이 영역에서 읽고 쓰기를 통해서 정보를 주고받을 수 있다.
  - message passing보다 더 빠르다. <- shared memory의 경우 system call을 shared memory region을 만드는 데에만 쓰이지만, message passing의 경우 그 자체로 system call로 구성되므로 kernel의 개입이 많다.
- message passing : 말 그대로 서로서로 메세지를 주고받으면서 소통하는 것을 말한다.
  - conflict를 피할 필요가 없기 때문에 적은 양의 데이터를 주고받는데 유용하다.
  - distributed system에서는 shared memory보다 구현하기 쉽다. (ex: 네트워크로 통신하는 서로 다른 두 컴퓨터)

IPC in Shared-Memory Systems

shared memory를 만드는 프로세스의 address space 내부에 shared-memory가 존재하게 된다. 그리고 기본적으로 서로 다른 프로세스로의 메모리 접근은 제한되어 있기 때문에, 설정한 shared-memory영역에 대해서 이 제한을 해제해야 한다. 동시에 같은 장소에 write하는 것을 주의해야 한다.
producer-consumer problem : 한 프로세스는 데이터를 생성, 나머지 한 프로세스가 그 데이터를 소비한다.
- 서순이 잘 정렬되어 소비자가 아직 생성되지 않은 아이템을 소비하지 않게 주의해야 한다.
- unbounded buffer : buffer의 size의 limit가 없다. -> 생산자는 항상 새 아이템을 만들 수 있고, 소비자는 새 아이템이 만들어질 때 까지 기다려야 함.
- bounded buffer : buffer의 고정된 사이즈가 존재. -> consumer는 버퍼가 비어있으면 기다려야 하고, 생산자는 버퍼가 꽉 차 있으면 기다려야 한다.

IPC in Message-Passing Systems

message-passing facility는 적어도 아래의 두 연산이 필요하다:
- send(message)
- receive(message)
message를 보낼 때 고정된 크기로 보낸다 -> system-level에서의 구현은 쉽지만, programming은 어렵다.
반대로 variable 크기로 보낸다 -> system-level에서의 구현은 어렵고, programming은 쉽다 -> tradeoff!
메세지를 주고 받기 위해서는 communication link가 필요하다. link와 send()/ receive()를 구현하는 logical한 방법들 :
- Direct or indirect communication
- Synchronous or asynchronous communication
- Automatic or explicit buffering

Naming

프로세스끼리 통신하기 위해서는 서로를 부르는 방식이 필요한데, direct 또는 indirect 방식이 존재한다.
- direct communication : 수신자를 직접 명시해 주어야 소통할 수 있다.
  - send(P, message) : P에게 메세지 보내기
  - receive(Q, message) : Q에게서 메세지 받기
  - communication link의 경우 link는 서로 소통하고자 하는 프로세스마다 자동으로 생성되고, 그 프로세스들은 서로의 identity만 알면 소통가능하다.
  - A link is associated with exactly two processes.
  - Between each pair of processes, there exists exactly one link.
    ...

Synchronization

Communication between processes : send()와 receive()를 통해 이루어짐
- Blocking send : message가 process나 mailbox가 receive하기 전까지 sending process가 block된다.
- Nonblocking send : 받던말든 보내고 바로 자기 할일 함.
- Blocking receive : message가 오기 전까지 receiver가 block된다.
- Nonblocking receive : 올바른 메시지나 null을 받는다. (대기 X)

Buffering

communicating process에 의해 교환되는 메시지들은 temporary queue에 담기게 된다. 이 queue들의 구현 방법은 다음과 같다.
- Zero capacity(no buffering) : queue의 길이가 0이어서 메시지가 보관될 수 없음 -> sender는 무조건 수신자가 받기 전까지 block되어야 한다.
- Bounded capacity : n개의 메시지만 보관될 수 있음 -> 꽉 차 있지 않은 경우에 sender는 메시지 보내고 다른 작업 가능. But 꽉 차 있는 경우 : sender는 queue가 빌 때 까지 block되어야 한다.
- Unbounded capacity : queue의 길이가 제한되지 않음 -> sender는 block되지 않는다.

Examples of IPC Systems

POSIX Shared Memory

shared memory를 memory-mapped file(메모리에 맵핑된 파일인듯)을 통해서 구현한다. shared_memory 객체를 shm_open() system call을 통해 만든다.
fd = shm_open(name, O_CREAT | O_RDWR, 0666);
첫 인자 : shared_memory 객체의 이름; 이 객체에 접근하기 위해서 이 이름이 필요하다.
성공 시 이 shared_memory 객체의 fd값이 리턴됨.
실패 시 -1이 리턴됨.
ftruncate()함수로 그 객체의 크기를 설정할 수 있다.
ftruncate(fd, 4096); -> 그 객체의 크기를 4096 bytes로 설정함.
mmap() 함수는 shared-memory 객체를 포함하는 memory-mapped file을 만들어준다. memory-mapped file에 대한 포인터를 리턴해 줘서 shared-memory 객체에 접근할 수 있게 해준다.
- shm_open 함수?
```
#include <sys/mman.h>
#include <sys/stat.h>	/* mode 상수포함 헤더 */
#include <fcntl.h>		/* O_* 상수포함 헤더 */

int	shm_open(const char *name, int oflag, mode_t mode);
int	shm_unlink(const char *name);
```
  - 컴파일 시 -lrt를 해주어야 함.
  - 이름이 "/somename" 형태여야 한다. (/로 시작함)
  - new shared memory object는 처음에 zero length를 가지는데, 이를 바꾸기 위해 ftruncate 함수를 사용할 수 있다.
  - (ftruncate과) mmap 이후에 file descriptor는 닫아도 메모리 매핑에 상관이 없다.
다 썼으면 shm_unlink()를 써서 kernel의 메모리 영역을 할당 해제해 주어야 한다. 아니면은 다음 재부팅시까지 남아있음.
자세한건 https://velog.io/@dandb3/Memory-Mapping 참조.

Pipes

두 프로세스들이 소통하는데 pipe가 매개 역할을 함. 초반 UNIX 시스템의 IPC 매커니즘 중 하나이다.
파이프를 구현하는데 고려해야 하는 4가지 문제들
1. pipe가 단방향인가 양방향인가?
2. 양방향인 경우, half duplex(동시에 한 방향으로만 전송 가능)인가 full duplex(동시에 양 방향으로 전송 가능)인가?
3. 소통하는 프로세스간에 relationship(parent-child관계처럼)이 존재해야만 하는가?
4. pipe가 네트워크를 통해서 소통가능한가 아니면 같은 machine에서만 동작하는가?
Ordinary Pipes
- ordinary pipes는 두 프로세스가 기존의 producer-consumer 관계를 통해 소통하도록 한다.
- producer가 pipe의 한쪽으로 write하고(write end), consumer가 다른 한쪽으로 읽어들인다(read end).
- 그러므로 단방향 소통만 가능하다. -> 양방향 소통을 하고싶으면 파이프를 2개 쓰면 됨.
- UNIX : pipe(int fd[])로 파이프를 만든다.
  - fd[0] : pipe의 read end
  - fd[1] : pipe의 write end
  - pipe는 file의 특별한 타입으로 취급되어 read(), write() system call로만 접근할 수 있다.
- ordinary pipe의 경우 파이프를 만든 프로세스의 외부에서는 접근할 수 없다. 그래서 보통 parent process가 pipe를 만들고 fork()를 통해 자식 프로세스와 소통하게 된다. <- 자식 프로세스는 부모로부터 open files를 상속받고, 파이프는 special type of file이므로 자식은 부모로부터 파이프 또한 상속받는다. -> 결국 하나의 machine 내부에서만 샤용 가능하다.
- pipe가 EOF를 감지하기 위해서 쓰지 않는 fd들을 닫아주는 것이 필요하다.
- pipe는 kernel memory에 buffer 형태로 생성이 된다.
Named Pipes
- ordinary pipes들은 process가 서로 소통하는 도중에만 존재한다. -> 소통을 끝내고 프로세스가 종료되면 pipe는 사라진다.
- communication은 양방향일 수 있고, 부모-자식 관계도 필요하지 않다.
- named pipe는 여러 프로세스가 사용할 수 있고, writer도 여럿 존재할 수 있다.
- 소통하는 프로세스들이 다 종료해도 파이프가 없어지지 않는다.
- UNIX에서 FIFO로 불려짐. 만들어지면 파일 시스템의 일반 파일로 분류된다.
- mkfifo()를 통해 만들어질 수 있고, open(), read(), write(), close() system call을 통해서 사용할 수 있다.
- 일반 파일과 동일하게 explicit하게 제거해 주어야 없어진다.
- 양방향 통신을 지원하지만, half-duplex만 허용된다. -> 보통 두 개의 FIFO가 양방향 통신에 사용된다. 또한, 소통하는 프로세스들은 같은 machine에 존재해야 함. (intermachine communication을 하려면 socket이 사용되어야 한다.)

TMI

tmpfs???
- Temp File System의 약자.
- 실제로 물리적 파일에 저장하거나 디렉토리를 생성할 수 있는 공간이 아니다.
- 메모리를 파일처럼 사용할 수 있게 하는 파일 시스템이다. -> 읽기/쓰기가 메모리에서 이루어짐 -> 속도 개빠름, but 재부팅 시 지워진다.