2020-11-23 에 겪었던 나의 시행착오

다른곳에 저장해두었던 내용을 블로그에 옮겨본다.

 

-v 옵션을 처음 봤을 당시, 보고 문득 혼자 상상의 나래를 펼치며 망상을 했었다...

공부하다가 이해가 안가는 부분을 여기저기 물어보다 깨닫게 되곤한다.

게다가 물어보면 정말 검증 방법까지 알려주시는 감사한 현업자 선배님들...

 

 

Docker Container Volume

필요한 이유

  • container가 run 명령에 의해 시작될 때는 read-only image로부터 시작되어 container의 filesystem은 read-only layer 위에 read-write layer로 만들어진 virtual filesystem 이다.
  • 실제 Container를 시작한 후 만들어진 파일은 persistent filesystem에 저장된 것처럼 느껴지지만, 실제로는 디스크에 쓰여지는 것이 아니라 in-memory file system 에 쓰이는 것이므로, container가 종료되면 사라진다.
  • 동일한 image로부터 container를 다시 만들면, 저장한 데이터는 사라지게 된다.
  • 만약 DB를 사용하는 앱이라면, DB에 record 를 저장하였으나, container 가 종료되면 DB 테이블이 사라지게 된다.

⇒ 이러한 문제를 해결하기 위해 Container Volume을 제공

  • -v 옵션을 사용해 docker run할 때 이미지만 변경하고 같은 볼륨을 마운트 하는 식으로 사용한다.

Docker Volume 설명

  • -v <host path> : <mounting point path in container>
  • volume 을 mount 하여 실제 디스크에 영구적으로 데이터를 저장하여, container가 종료되어도 영구적으로 데이터를 저장할 수 있다
  • but, 단점도 있다.
  • container의 장점 중의 하나는 container들 사이에 filesystem을 통한 간섭이 없어서 보안이 뛰어나다는 것인데 volume 기능은 잘못된 코딩 또는 바이러스에 의해 이러한 장점이 훼손될 수 있다.

Docker Volume 3가지 type

  1. Host volume
    • docker run -v /home/mount/data:/var/lib/mysql/data
    • 정확하게 mount할 경로를 지정
  2. named volume
    • docker run -v name:/var/lib/mysql/data
    • data 참조를 쉽게 하기 위해 이름으로 설정
  3. Anonymous volume
    • docker run -v /var/lib/mysql/data

 

 

 

 

 

동아리 현업 선배님들한테 항상 많은 도움을 받는다..

'Tech-Talk' 카테고리의 다른 글

TCP connection 과 Streaming + QUIC 에 대한 고찰  (0) 2021.08.29

같이 스터디하는 분들끼리 TCP connection에 대해 의견이 분분해서 토론이 시작되었고, 추가로 느꼈던 의문과 고민, 그 답을 찾아가는 과정을 남겨놓았습니다.

 

토론의 시작 질문

핸드폰으로 유튜브를 보던 중에 핸드폰의 IP가 변하면 TCP 연결이 끊어지나요?

 

상황 설명

  1. 와이파이에 연결되어 있다가 와이파이를 끊어서 Public IP가 바뀐다던가.
  2. 핸드폰을 들고 이동해서 IP가 바뀐다던가.

 

내 시나리오

TCP 연결이 끊어진다

 

서버사이드(유튜브)랑 클라이언트(핸드폰) 사이드로 나눠서 보면

  1. 둘이 TCP 연결되어있다가 클라이언트 IP가 변경되면 서버에서는 그걸 모른다.
  2. 따라서 서버에서는 계속해서 클라이언트에게 응답 패킷을 보낸다
  3. 근데 클라이언트는 그걸 못받는다. 왜? 기존 연결되어있던 IP가 바뀌었으므로
  4. 클라이언트는 바뀐 새 source ip로 TCP 연결되어있듯이 계속 서버에게 요청을 보낸다
  5. 서버는 TIME_OUT으로 기존 ip(라우터)와 연결이 끊긴다.
  6. 클라이언트도 계속해서 요청을 보냈는데 서버의 응답을 못 받아서 TIME_OUT으로 연결이 끊긴다.
  7. 연결이 끊겼으니 클라이언트가 TCP 연결을 다시 시도한다.
  8. 새로운 TCP 연결이 생긴다.

 

다른 분 시나리오

TCP 연결이 끊어 지지 않는다.
  1. 계층화의 개념으로 생각해보면 TCP 연결은 port만으로 연결이 되기 때문에 IP는 상관이 없다.
  2. Transport(전송) 계층 패킷의 헤더를 생각해보면 Source Port, Destination Port 만 있지 않은가?
  3. TCP는 전송계층 프로토콜 이므로, IP가 바뀌어도 TCP 연결이 끊기지는 않는다.

 

첫 번째 결론

일단 토론 끝에 내린 결론은

  • TCP 연결하는 통신에서도 패킷의 <소스 IP, 소스 port, 타깃 IP, 타깃 port>를 TCP control block으로 사용하기 때문에, 소스 IP가 변경되면 재 연결된다.

입니다!

 

 

추가 문제

TCP 연결이 끊어지느냐에 대한 것은 YES로 결론이 났다. 하지만 여기서 문제가 하나 더 있었으니,

유튜브는 스트리밍이므로 TCP 통신이 맞는가 UDP 통신이 맞는가?

우선 이론적으로 배운것을 바탕으로 시나리오를 작성해보고, 다른 개발자분들과 이야기를 나눠보며 새로 생긴 이슈들이다.

 

1. TCP는 신뢰성을 보장하기 위한 연결 지향 프로토콜이다 보니 흐름 제어나 혼잡 제어 등을 해서 속도가 느린 반면, UDP는 비연결성 프로토콜로 속도가 빨라서 보통 실시간 스트리밍 같은 곳에 많이 쓰인다.

 

2. 따라서 실시간 스트리밍 서비스는 UDP일 것이다.

 

3. 그러나, 유튜브 컨텐츠를 보는 것이 리얼타임 통신은 아니지 않은가?

 

4. 그렇다면 굳이 UDP를 쓸 이유도 없어진다.

 

5. 그럼 TCP인가?? 

 

6. 또한 HTTP 는 TCP/IP 기반 응용 프로토콜이다.

 

7. 브라우저는 UDP를 지원하는가..?

 

등의 끊이지 않는 의문이 생겼다.

 

이 의문들을 당장 해결하기 위해서, 바로 유튜브를 켜고, 개발자 도구를 열어서, 당장 Response Header를 살펴보았다.

유튜브 컨텐츠의 HTTP 헤더

그랬더니 예상과는 전혀 다른 quic라는 프로토콜이 튀어나오는 것이었다....!!

 

여기서 멈출 수는 없었다.

 

그렇게 quic 에 대해 알아보았다.

 

 

QUIC (Quick UDP Internet Connections)

QUIC 프로토콜은 Google에서 개발된 프로토콜로 현재 표준 등록을 진행 중이라고 한다.

우선 UDP 위에 QUIC 프로토콜은 얹고 HTTP를 얹은 게 눈에 띈다.

거기에 TCP-like 혼잡 제어 + loss recovery 라니...

 

간단하게,

UDP로 3-way-handshake 없애서 속도 올리고, QUIC로 TCP-like 신뢰성을 추가한다 라는 소리로 들린다.

 

즉, UDP의 속도적 장점 + TCP의 신뢰성 장점을 합친 것이 이 프로토콜의 목표인 것 같다.

 

 

TCP vs QUIC

 

시간적 이점이 왜 나타나는지를 조금 더 자세히 살펴보자.

 

TCP + TLS에서 동작하는 HTTP/2 프로토콜에는 HOL(head-of-line) 문제가 있었다.

  • HOL(head-of-line): HTTP/2에서 TCP 연결을 통해 패킷 전송이 일어날 때, 한 패킷에 문제가 생기면 다른 패킷 전송이 영향이 간다.

이에 QUIC는 독립 스트림을 여러 개 만들어 이 문제를 피하고자 하는 것이 핵심이다.

또한 hanshake 과정의 시간도 비교가 안된다.

 

 

 

결론

1. TCP 연결이 되어있다가 Client IP (Source IP)가 바뀌게되면 TCP control block으로 사용하는 패킷의 <소스 IP, 소스 port, 타깃 IP, 타깃 port>가 바뀌므로 TCP connection 이 끊기고 재연결된다.

 

2. 유튜브 스트리밍 서비스는 UDP 기반 QUIC 프로토콜을 이용한다.

 

여담

구글의 대부분의 제품에는 이미 quic 가 들어가 있지만, 아직 표준이 지정되지 않았고 UDP 기반의 프로토콜을 서버가 받아들이는 데 있어서 최적화나 검증되지 않은 부분이 많기 때문에 항상 속도가 더 빠르다고 장담할 수는 없다.

 

다만, 표준이 지정되고 시대가 HTTP/3로 넘어가게 되면 IE의 몰락처럼, TCP 기반이 아닌 UDP 기반의 QUIC를 당연히 사용하는 시대가 올 수 있지 않을까.

(기술은 늘 변하는 것이고, 문제를 해결하는 데 있어서 더 좋은 해결책이 나왔다면 자연스레 바뀌기 마련이라 생각한다..)

 

 

 

 

이 내용들은 제가 공부하며 느꼈던 의문과 고민, 그 답을 나름대로 찾아가는 내용입니다.

아직 많이 부족하니. 틀린 부분은 얼마든지 지적해주세요!

 

 

Reference

 

언제나 즐거운 질문과 답변에서 이어지는 티키타카

1. 개발자 커뮤니티에 질문


2. 같은 동아리 출신 개발자 분들께 질문

 

'Tech-Talk' 카테고리의 다른 글

Docker -v 옵션에 대한 혼돈과 깨달음  (2) 2021.08.29

1. 동시성 제어 (Concurrency Control)

  • Context-Switch : CPU에서 running 중이던 process를 PCB에 store 하고, 다른 PCB의 register 정보(PC, IR)를 CPU에 load 해오는 상황
  • Concurrency-Control : Context-Switch 를 통해서 time-sharing을 함. 즉, 동시성 = 시분할

 

2. Concurrent vs Parallel

  • Concurrenct : 시분할
  • Parallel : multicore에서 실제 동시에 병렬적으로 실행 Parallelism
    1. data parallelism
    2. task parallelism

 

3. 동기(synchronous) vs 비동기(asynchronous) / blocking vs non-blocking

  • Synchronous VS Asynchronous
    • 두 가지 이상의 대상(메서드, 작업, 처리 등)과 이를 처리하는 시간으로 구분한다.
    • Synchronous
      • 호출된 함수의 리턴하는 시간과 결과를 반환하는 시간이 일치하는 경우
      • 함수의 결과를 호출한 쪽에서 처리
    • Asynchronous
      • 호출된 함수의 리턴하는 시간과 결과를 반환하는 시간이 일치하지 않는 경우
      • 함수의 결과를 호출한 쪽에서 처리하지 않는다.
      • 호출되는 함수에게 callback을 전달해서, 호출되는 함수가 전달받은 callback을 실행
  • Blocking VS Non-Blocking
    • 호출되는 대상이 직접 제어할 수 없는 경우 이를 구분할 수 있다.
    • Blocking: 호출된 함수가 자신의 작업을 모두 마칠 때까지 호출한 함수를 기다리게 만든다.
    • Non-Blocking: 호출된 함수가 바로 리턴해서 호출한 함수에게 제어권을 준다.

 

4. 동기화 객체의 종류

  • 스레드 동기화 방법
    1. 실행 순서의 동기화
      • 스레드의 실행 순서를 정의하고, 이 순서에 반드시 따르도록 하는 것
    2. 메모리 접근에 대한 동기화
      • 메모리 접근에 있어서 동시 접근을 막는 것
      • 실행의 순서가 중요한 상황이 아니고, 한 순간에 하나의 스레드만 접근하면 되는 상황을 의미
  • 동기화 기법의 종류
    1. 유저 모드 동기화
      • 커널의 힘을 빌리지 않는(커널 코드가 실행되지 않는) 동기화 기법
      • 성능상 이점, 기능상의 제한
      • Ex) 크리티컬 섹션 기반의 동기화, 인터락 함수 기반의 동기화
    2. 커널 모드 동기화
      • 커널에서 제공하는 동기화 기능을 활용하는 방법
      • 커널 모드로의 변경이 필요하고 이는 성능 저하로 이어짐, 다양한 기능 활용 가능
      • Ex) 뮤 텍스 기반의 동기화, 세마포어 기반의 동기화, 이름있는 뮤텍스 기반의 프로세스 동기화, 이벤트 기반의 동기화

 

 

5. 동기화 관련 문제들

  1. busy-waitingsleep and wakeup으로 해결
  2. 생산자 소비자 문제 (Producer-Consumer)
    • 생산자 (producer) : 버퍼에 정보를 삽입
    • 소비자 (consumer) : 버퍼에서 정보를 제거
    • 버퍼가 가득 차 있다면? 생산자를 sleep --> 소비자 수행 후, wakeup
    • count에 대한 접근 → Race-Condition (경쟁 조건) → wakeup signal 분실 가능
    • 해결 : 세마포어 활용
  3. 식사하는 철학자들 문제
    • 철학자는 스파게티를 먹기 위해 양옆의 포크를 동시에 들어야 한다.
    • 이때, 전부 왼쪽 포크를 먼저 들면, 오른쪽 포크를 전부 못 들어 무한정 기다리게 된다.
    • 즉, 제한된 수의 자원에 접근하는 문제
    • 동시성 + 데드락 : 여러 프로세스가 동시에 돌아갈 때 교착 상태에 빠지는 원인
    • 해결 : 동시성을 제거 - 필요한 포크가 사용 중이라면, 배고픈 철학자라도 블락된다
  4. 독자 저자 문제 (The Readers and Writers Problem)
    • 식사하는 철학자 문제가 I/O와 같이 제한된 수의 자원에 접근하는 문제라면
    • 읽는 자 쓰는 자는 데이터베이스에 접근하는 모델
    • 여러 리더가 존재 가능
    • Reader와 Writer의 배타적 접근
    • 해결 : 뮤 텍스 세마포어
  5. 잠자는 이발사 문제
    • 한 명의 이발사, 하나의 이발용 의자, 기다리는 손님을 위한 n개의 의자
    • 손님이 없으면 이발사는 sleep
    • 손님이 오면 이발사는 wakeup
    • 이발 중 손님이 오면 대기용 의자에서 기다림
    • 대기용 의자도 만석이면 손님은 그냥 이발소를 떠남
    • ⇒ 이발사와 손님이 Race-Condition에 빠지지 않도록 하는 것
    • 해결 : 뮤 텍스
      • 한 번에 한 명만이 동작 상태를 바꿀 수 있게 한다.
      • 이발사 : 뮤 텍스 얻어야 대기실 손님 확인 가능
      • 손님 : 뮤텍스 얻어야 이발소 들어갈 수 있음, 대기실 or 의자에 앉으면 뮤텍스 반납
    • 복수의 잠자는 이발사 문제 : 세마포어 필요

 

6. Critical Section (임계 영역)

  • 멀티 스레딩에 문제점에서 나오듯, 동일한 자원을 동시에 접근하는 작업을 실행하는 코드 영역
  • Race Condition을 유발하는 코드 블록
  • (e.g. 공유하는 변수 사용, 동일 파일을 사용하는 등)

 

7. Race Condition 이란?

  • 공유 자원에 대해 여러 프로세스/스레드가 동시에 접근을 시도하는 상황
  • 즉, 하나의 자원을 두고 경쟁하는
  • 타이밍에 따라서 결과가 다를 수 있어, 자료의 일관성을 해치는 결과가 나타남
  • ex) 은행에서 출금하는 스레드 사이에서 발생하는 경우 balance가 덜 줄어듦 → 심각한 문제
    1.  

 

8. Race Condition이 발생하는 경우

  • Shared resource에 access 했는데 동기화를 하지 않으면 발생
  1. 커널 작업을 수행하는 중에 인터럽트 발생
    • 문제점 : 커널 모드에서 데이터를 로드하여 작업을 수행하다가 인터럽트가 발생하여 같은 데이터를 조작하는 경우
    • 해결법 : 커널 모드에서 작업을 수행하는 동안, 인터럽트를 disable 시켜 CPU 제어권을 가져가지 못하도록 한다.
  2. 프로세스가 'System Call'을 하여 커널 모드로 진입하여 작업을 수행하는 도중 문맥 교환이 발생할 때
    • 문제점 : 프로세스 1이 커널 모드에서 데이터를 조작하는 도중, 시간이 초과되어 CPU 제어권이 프로세스2로 넘어가 같은 데이터를 조작하는 경우 ( 프로세스2가 작업에 반영되지 않음 )
    • 해결법 : 프로세스가 커널모드에서 작업을 하는 경우 시간이 초과되어도 CPU 제어권이 다른 프로세스에게 넘어가지 않도록 함
  3. 멀티 프로세서 환경에서 공유 메모리 내의 커널 데이터에 접근할 때
    • 문제점 : 멀티 프로세서 환경에서 2개의 CPU가 동시에 커널 내부의 공유 데이터에 접근하여 조작하는 경우
    • 해결법 : 커널 내부에 있는 각 공유 데이터에 접근할 때마다, 그 데이터에 대한 lock/unlock을 하는 방법

 

9. Thread-safe 의미, 구현

  • 의미
    • 멀티스레드 환경에서 여러 스레드가 동시에 하나의 객체 및 변수(공유 자원)에 접근할 때, 의도한 대로 동작하는 것
  • 구현
    • 결국 동기화
    • 2개의 critical regionmutual exclusive 하게 수행되도록 막아서, 2개의 thread를 synchronize 하면 Race-condition을 없앨 수 있다.

 

10. Critical Section Problem (임계 영역 문제)를해결하기 위한 조건

  1. 상호 배제 (Mutual Exclusion) : 한 프로세스가 임계 구역에 들어가 있으면 다른 프로세스 들어갈 수 없다.
  2. 진행 (Progress) : 임계구역에 들어간 프로세스 없다면 어느 프로세스가 들어갈지 적절히 선택
  3. 한정 대기 (Bounded Waiting) : 기아 방지를 위해 한 번 들어갔다 나온 프로세스는 다음에 들어갈 때 제한을 준다. - no Starvation

(+) CPU의 속도 등에 대한 어떠한 가정도 하면 안 된다

 

 

11. Mutex (Mutual Exclusive), 상호 배제

  • Mutual exclusive 하게 수행하도록 하여 synchronize 하는 것
  • 그러므로 Race Condition을 없앤다.
  • 화장실이 하나뿐인 식당, 열쇠 1개
  • 여러 프로세스/스레드가 공유된 자원에 접근하는 것을 막는 것
  • 여러 프로세스가 공유 자원 사용하려 할 때 번갈아 가며 사용하도록 함
  • 임계 구역 내에서 인터럽트, 교착상태, 무한반복 발생하지 않도록 해야 함
  • 키가 1개인 세마포어라고 볼 수 있다. (이진 세마포어)
  • 구현 방법
    • 2개 프로세스 기준 : 데커 알고리즘, 피터슨 알고리즘
    • 여러 개 프로세스 기준 : Lamport의 빵집 알고리즘

 

 

12. Critical Section Problem 해결 방법 4가지

  1. Lock
  2. Semaphore
  3. Monitor
  4. Message

 

13. Lock

  • 자원을 사용하는 동안 들어오지 못하도록 잠구는 것
  • 하나의 자원에 여러 스레드가 동시에 접근하는 것을 조율해준다.

1) 기본형

  • 동시에 공유 자원에 접근하는 것을 막기 위해 Critical Section에 진입하는 프로세스는 Lock을 획득하고 Critical Section 을 빠져나올 때, Lock 을 방출함으로써 동시에 접근이 되지 않도록 한다.
while (lock == 1);
lock = 1;
Critical_region();
lock = 0;
  • 한계 : lock 이 0 일 때 두 스레드가 동시에 진입하면 문제!

2) Spin Lock

  • busy waiting을 사용한 lock
  • 장점 : lock이 해제될 때 context-switching 이 없어서, 오버헤드 없이 critical section 접근 가능
  • 단점 : 어떤 스레드가 락을 오래 소유하면, CPU 낭비
  • 한계 : Progress를 만족하지 않음 - 010101 번갈아서 들어와야 함 / 000 이면 실행 안됨
  • 언제 사용? 멀티-스레드에서 critical section 이 아주 작거나, 빠른 처리 가능할 때
while(True) {
	while (turn != 0);
	Critical_region();
	turn = 1;
	Noncritical_region();
}

 

while(True) {
	while (turn != 1);
	Critical_region();
	turn = 0;
	Noncritical_region();
}

 

3) Peterson's Solution

  • 소프트웨어적으로 이 방법을 쓰면 해결 가능하지만, 오버헤드가 크다

4) TSL (Test and Set Lock) instruction

  • 하드웨어적으로 제공되는 명령어로 atomic 하게 실행된다.
# 하드웨어에서 이런 명령어를 제공
bool Test_and_Set(bool *flag) {
	bool old = *flag;
	*flag = True;
	return old;
}

lock = false;
repeat
	while Test_and_Set(lock) do no-op;
	Critical Section
	lock = false;
	Remainder Section
until false
  • 문제
    • Spin Lock 이기 때문에 CPU를 계속 써야 함 (Lock 값 계속 체크해야 함)

 

 

14. Sleep and Wakeup

  • busy-waiting 해결 → 임계 구역 진입이 허용되지 않을 때, CPU 시간을 낭비하는 대신 블록 하는 프로세스 간 통신 고려
    • sleep : 호출자를 block → 다른 프로세스가 깨울 때 (wakeup)까지 보류
    • wakeup
  • 발생 문제 : 생산자 - 소비자 문제 (한정된 버퍼 문제)
    • 생산자 (producer) : 버퍼에 정보를 삽입
    • 소비자 (consumer) : 버퍼에서 정보를 제거
    • 버퍼가 가득 차 있다면? 생산자를 sleep --> 소비자 수행 후, wakeup

 

 

15. Semaphore

  • 화장실이 여러 개 있는 레스토랑, 열쇠 = 칸 개수만
  • 현재 공유자원에 접근할 수 있는 프로세스/스레드 수를 나타내는 값을 두어 상호 배제
  • Lock시 특정 수만큼의 카운트를 더하고
  • Unlock시 빼주는 형식으로 처리
  • 이런 락을 슬립( Sleep ) 가능한 락이라고 함
  • Up, Down은 atomic 하게 동작
  • 생산자 소비자 문제의 근본적 해결
  • 동기화해야 하는 대상이 여러 개일 때 사용

1) 카운팅 세마포어

  • 가용한 개수를 가진 자원에 대한 접근 제어용으로 사용되며, 세마포는 그 가용한 자원의 개수로 초기화된다. 자원을 사용하면 세마포가 감소, 방출하면 세마포가 증가한다.
  • 생산자 소비자 문제와 비교하기
  • count 하나로 표현되던 부분들이 up, down을 이용하여 mutex, empty, full로 표현
#define N 100   // 버퍼 용량
int mutex = 1;  // 공유 데이터를 위한 mutex
int empty = n   // 빈 용량
int full = 0    // 찬 용량

void producer(void) {
	int item;

	while(TRUE) {
		item = produce_item();  // item 생성
		down(&empty);           // if 꽉차지 않았으면 empty--;
		down(&mutex);           // mutex = 0 으로 해서, lock 처리
		insert_item(item);      // 버퍼에 추가
		up(&mutex);             // mutex = 1 으로 해서, unlock 처리
		up(&full);
	}
}

void consumer(void) {
	int item;

	while(TRUE) {
		down(&full);
		down(&mutex);
		item = remove_item();  // 
		up(&mutex);
		up(&empty);
		consume_item(item);  
	}
}

2) 이진 세마포어 (MUTEX)

  • MUTEX라고도 부르며, 상호 배제의 (Mutual Exclusion)의 머릿글자를 따서 만들어졌다. 이름 그대로 0과 1 사이의 값만 가능하며, 다중 프로세스들 사이의 Critical Section 문제를 해결하기 위해 사용한다.

 

16. Monitor

  • 동기화를 구현하기 위한 특수 프로그램 기법
  • 특정 공유 자원을 프로세스에게 할당하는 데 필요한 데이터와 이 데이터를 처리하는 프로시저로 구성
  • 자료 추상화, 정보 은폐 개념을 기초, 병행성 구조
  • 상호 배제가 low-level 단에서 지원됨
  • → "단 하나의 프로세스만 한 순간에 모니터에서 활동할 수 있다."
  • 생산자-소비자 문제 해결
    • 조건 변수 wait, signal 도입
    • sleep, wakeup과 달리 모니터에서는 자동적으로 상호 배제가 됨→ 문맥교환 될 걱정하지않고 연산 완료 가능
    • → wait, signal은 상호배제가 아님

 

17. Message Passing

  • send / receive ; 시스템 호출 일종
  • acknowledgement 분실 문제 -> 메시지 구별 필요
  • 인증 --> 프로세스의 유일성 보장
  • 생산자 - 소비자 문제
    • 공유 메모리가 아닌, 메시지 전달로 해결
    • 가정
      1. 모든 메시지는 동일한 크기
      2. 메시지는 운영체제에 의해 자동 버퍼링
    • 방법
      1. 소비자는 시작할 때, N개의 빈 메시지를 생산자에게 보냄
      2. 생산자는 소비자에게 전달할 아이템을 생산하면, 빈 메시지 수신 → 아이템이 들어 있는 메시지 전송

'CS > 운영체제 (OS)' 카테고리의 다른 글

8. IPC (Inter-Process Communication)  (0) 2021.08.11
7. 프로세스 vs 스레드  (0) 2021.08.11
4. 프로세스의 주소 공간  (1) 2021.08.08
3. 인터럽트 (Interrupt)  (1) 2021.08.08
2. 커널 (Kernel)  (0) 2021.08.06

+ Recent posts