[운영체제] 프로세스 간 통신

📌 프로세스 간 통신 

 

💡 목표 

공유 메모리와 메시지 전달을 통한 프로세스 간 통신에 대해 이해하고 비교할 수 있다. 

 

 

💡 개념 

프로세스들은 독립적이거나 혹은 협력적인데,

협력 프로세스는 데이터 공유를 포함하여, 프로세스들에게 영향을 주거나 받음. 

 

협력을 허용하는 환경을 제공하는 이유는

✔️ 정보를 공유할 수 있고,

✔️ 계산을 가속화할 수 있으며,

✔️ 모듈 형태로 프로세스를 구성할 때 필요할 수 있고,

✔️ 개별 사용자들이 여러 프로세스들을 작업할 때 편리하게 활용할 수 있기 때문이다.  

 

 

 

💡 IPC의 모델들 | (Inter Process Communication, IPC) : 프로세스들간의 통신 

 

a) 공유 메모리 shared memory
b) 메시지 전달 

 

 

1. 공유 메모리 

통신하는 프로세스들이 공유 메모리를 구축해야한다. 

 

📝 생산자 (프로세스 정보 생성) - 소비자 (프로세스 정보 소비) 문제 

ex. 웹 서버 (생산자) - 웹 브라우저 (소비자)

만약 소비자가 생산자가 생산하는 속도보다 빠르게 소비하면, 소비자는 기다리는 문제가 생길 수 있음. 

이 문제를 생산자 - 소비자 문제라고 하는데, 

 

⭐️ 해결책으로는 공유 메모리 사용하는 것이다. ⭐️

공유 메모리는 버퍼이며, 버퍼는 반드시 사용이 가능해야한다.

공유 메모리 (버퍼)를 생산자는 정보를 생산하고, 소비자는 정보를 소비하며 동시에 통신하는 방법이다. 

 

📝 버퍼의 종류 

무한 버퍼 : 버퍼의 크기의 실질적인 한계가 없음. (현실적으로 불가능)

유한 버퍼 : 버퍼 크기 고정 

버퍼가 비어있으면 -> 소비자는 반드시 대기

모든 버퍼가 채워져 있으면 -> 생산자가 대기. 

 

 

2. 메시지 전달 

- 공유 메모리처럼 동일한 주소 공간을 공유하지 않고도 프로세스들이 통신을 하고, 그 동작을 동기화할 수 있도록 허용하는 기법이다. 

- send (message) - receive (message) 연산을 제공.

- 메시지는 고정 길이 일수도, 가변 길이 일수도 있음. 

- 통신 연결 (commnuication link)을 통해 프로세스 간 메시지를 송수신한다. 

 

논리적 구현 방법으로는,

✔️ 직접, 간접 통신

✔️ 동기식, 비동기식 통신

✔️ 자동, 명시적 버퍼링 

 

1) 직접 통신

- 통신을 원하는 각 프로세스는 통신의 수신자 혹은 송신자의 이름을 명시해야한다. 

- 연결(link)가 자동으로 생성

- 서로의 신원이 확실하기 때문에 연결은 정확히 두 프로세스들 사이에서만 연관된다.

- 대칭 주소 지정 : 발신자, 수신자 프로세스 모두 이름 지정하여 통신.

- 비대칭 주소 지정 : 발신자만 수신자의 프로세스 이름 지정. 

 

2) 간접 통신 

- 메일함이나 포트로 메시지 송수신. (직접통신과 다르게 메일함, 포트같이 중간 매개채 존재)

- 두 프로세스는 프로세스가 공유된 경우에만 통신함. 

- 두 구성원이 모두 있는 경우에만 연결 설정 (공유 메일함 존재)

- 연결은 두개 이상의 프로세스와 연결이 가능.

- 프로세스의 각 쌍 상태에는 여러가지 서로 다른 연결이 존재. 

- 공유 메일함 : 프로세스 혹은 운영체제에게 소유권이 존재. 

 

3) 동기화 (동기 / 비동기)

[ Blocking 모드 (동기)] - 기다림

- send : 송신된 메시지가 수신될 때 까지 송신자를 블록 (정지)시킴. (혹은 큐에 메시지가 가득차있을 때에도 블록)

- receive : 이용 가능한 메시지가 있을 때까지 수신자를 블록 (정지)

 

[Non - Blocking 모드 (비동기)] - 안기다리고 처리 ㅇㅇ

- send : 메시지를 전달한 뒤 다른 작업을 처리. 

- receive : 유효한 메시지를 받거나 null 메시지를 수신. 

 

4) 버퍼링 

- 통신 프로세스 간 교환되는 메시지는 직접적이든 간접적이든 임시 대기열에 존재. 

 

📝 임시대기열을 구현하는 방법들 

 

[ 용량 zero (최대 길이 0)]

- 발신자는 수신자가 메시지를 받을 때까지 차단. 

[ 제한된 용량 (유한 길이 n) ]

- 연결이 가득 차면 발신자는 대기열 공간이 확보될 때까지 차단. 

[ 무한 용량 ]

- 발신자는 절대 차단하지 않음. 서버 부담도 있고.. 예측하기도 어려움 

 

 

	공유 메모리	메시지 전달
구현 용이성	동시 사용이라 충돌 회피 관련 코드 짜야함.	이게 더 편함 (충돌 회피가 딱히 필요없음 큐로 처리돼서)
속도	이게 더 빠름 (시스템 콜 x)	커널을 사용해서 시스템 콜처리 때문에 좀 더 느림
분산 환경	공유 메모리가 캐시들 사이에서 왔다갔다 해야해서 캐시 일관성 지키다가 성능 떨어질 수 있음.	이게 더 성능 좋다.