🐢 chap14. 동시화

⭐ 14.1 동시성 문제

✅ 동시성 문제

???동시성을 더 탐구하다 보면 과연 어떤 종류의 문제가 발생할까???

• 발생할 수 있는 동시성 문제에 대한 여러 유형

• 1 고유한 동시성 문제 intrinsic concurrency issue

  • 동시성 제어 메커니즘이 없을 때만 존재하는 동시성 문제
  1. 서로 다른 인터리빙이 전체 상태를 다르게 만들 때 발생합니다.
  2. 모든 동시 시스템에 본질적으로 존재하기 때문에 ‘고유’
  3. 이 문제는 피할 수 없으며 제어 메커니즘을 이용해 다루어야 합니다
• 1. 동기화 이후 문제 post-synchronization issue
     • 동시성 제어 기술을 사용해서 발생 하는 문제
  2. 동시성 제어 기술로 인한 문제는 수정 사항이 적용된 이후에만 발생합니다.
  3. 동시성 문제를 고칠 때 속성 및 근본 원인이 완전히 다른 새로운 문제가 야기될 수 있다는 의미입니다.

✅ 1번과 2번 문제의 예시

1. 예를 들어 동일한 공유 데이터 자원에 모두 읽기/쓰기 접근 권한을 갖는 작업이 많다고 가정해 봅시다.
2. 이 작업들을 여러 번 실행하면 다른 작업을 위해 작성한 알고리듬이 예상대로 작동하지 않습니다.
3. 이러한 현상은 무작위로 발생하는 우연한 충돌 또는 논리적 오류로 이어집니다.
4. 이때 충돌 및 잘못된 결과가 무작위로 발생하고 예측할 수 없으므로, 동시성 문제라고 합리적으로 추정할 수 있습니다.

—> 고유한 동시성 문제 intrinsic concurrency issue

---

1. 알고리듬을 계속 분석해서 마침내 문제를 발견합니다. 공유 데이터 자원에 데이터 경쟁이 발생 했습니다.
2. 이제 공유 데이터 자원에 대한 접근을 제어하는 해결 방안을 떠올려야 합니다.
3. 해결 방법을 구현해 시스템을 다시 시작하면, 놀랍게도 일부 작업들이 데이터 자원에 아예 접근하지 못하게 되었음을 알게 됩니다.
4. 기술적으로 이러한 작업들을 기아 상태 starve라고 합니다.
5. 해결 방법을 도입한 결과, 첫 번째 문제와는 완전히 다른 성격을 지닌 새로운 문제가 나타났습니다.

—> 동기화 이후 문제 post-synchronization issue

⭐ 14.2 고유한 동시성 문제

✅ 고유한 동시성 문제

인터리빙은 그 자체로는 문제가 되지 않는다!

하지만 어떤 경우 인터리빙(속성)은 지켜야 할 일부 (불변해야 하는)제약 조건을 만족하지 못하게되고 바로 이때 인터리빙이 문제를 일으킨다

—> 그러므로 우리는 제약 조건이 변경되지 않으며 불변함을 유지하도록 동기화 메커니즘이라는

   제어 메커니즘을 도입해야 한다!

✅ 불변 제약조건

불변 제약 조건 invariant constraint

• 조건 및 기준에 대한 목록을 통해 표현되며 동시 시스템의 거의 모든 것에 해당 할 수 있는 제약조건
• 동시 시스템에서 발생하는 인터리빙은 기존에 정의된 불변 제약 조건을 만족해야 한다
• 시스템의 불변 제약 조건을 만족하지 않는 인터리빙이 존재할 때 시스템에 경쟁 상태가 발생했다고 한다.

1. [코드박스 14-1]의 [예제 14-1]은 단 하나의 불변 제약 조건이 있으며,
2. 공유된 카운터 변수에는 최종적으로 올바른 값이 있어야 하고 이 값은 3이어야 합니다.
3. 이 예제에는 세 개의 동시 작업이 있습니다. 모든 작업은 카운터를 1씩 증가해야 하며 이는 [코드 박스 14-1]의 목표로직입니다.

코드 박스 14-1 [예제 14-1] 하나의 공유 변수로 작업하는 세 개의 동시 작업이 있는 시스템

동시 시스템 {

	공유 상태 {
		카운터 : 정수 = 0
	}

	작업 T1 {
		A: 정수
		1.1. A = 카운터
		1.2. A = A + 1
		1.3. 카운터 = A
	}

	작업 T2 {
		B: 정수
		2.1. B = 카운터
		2.2. B= B + 1
		2.3. 카운터 = B
	}
	작업 T3 {
		A: 정수
		3.1. A = 카운터
		3.2. A = A + 1
		3.3. 카운터 = A
	}
}

• A, B 라는 같은 값을 갖는 지역변수는 해당 변수를 소유한 작업에 한정되어야 합니다.
• 작업은 공유된 변수에서 직접 작동하지 않으며 작업들은 오직 공유된 변숫값을 읽거나 변경할 수만 있습니다.

[코드 박스 14-1]의 예제는 경쟁 상태가 어떻게 논리적 오류를 일으키는지 보여줍니다. 공유 된 카운터 변수에서 값 2를 도출하는 인터리빙을 찾는 것은 쉽습니다.

코드 박스 14-2 [코드 박스 14-1]에 대해 정의된 불변 제약 조건을 위반하는 인터리빙

• [코드 박스 14-1]에 보이는 명령어 2.3과 3.3은 둘 다 공유된 카운터 변수의 내부에 값 2를 저장합니다. 이러한 상황을 데이터 경쟁이라고 합니다.

이번에는 C로 작성된 코드에서 세그멘테이션 오류를을 일으키는 상황입니다.

동시 시스템 {
공유 상태 {
char *ptr = NULL; // 힙 공간에 있는 메모리 주소를
// 가리켜야 하는
// 공유된 char 포인터는
// 기본값이 null이 됩니다.
}
작업 P{
1.1. ptr = (char*)malloc(10 * sizeof(char));
1.2. strcpy(ptr, "Hello!");
1.3. printf("%s\n", ptr);
}
작업 Q{
2.1. free(ptr);
2.2. ptr = NULL;
}
}

• 이 작업에 충돌을 일으키는 인터리빙은?

  • 명령어 2.1이 먼저 실행된다고 가정해봅시다.

    → ptr이 null이므로 작업 Q에서 충돌이 발생하겠지만 작업 P는 계속됩니다.

    → 그 결과 두 작업(스레드) 모두 같은 프로세스에 속하는 멀티스레딩 사용 사례에서, 두 작업을 포함하는 프로그램 전체에 충돌이 발생합니다. 충돌의 주요 원인은 null 포인터를 삭제하기 때문입니다.

  • 다른 인터리빙은 명령어 1.1 이후 1.2 이전에 2.2가 실행될 때입니다.

    → 이때 작업 P에서 충돌이 발생하지만, 작업 Q는 문제없이 완료됩니다. 이 충돌의 주된 이유는 null 포인터를 역참조하기 때문입니다.

• 경쟁탐지기 race detector
  • 경쟁탐지기 race detector를 사용하여 실행 빈도가 낮은 코드의 분기에서 기존의 경쟁 상태를 찾아내어 경쟁 상태를 유발하는 인터리빙을 식별할 수 있습니다
  • 정적 경쟁 탐지기 static race detector는 소스 코드를 살펴보고 관찰한 명령어에 기반해 모든 인터리빙을 만들려고 합니다.
  • 동적 경쟁 탐지기 dynamic race detector는 먼저 프로그램을 실행하고 나서 경쟁 상태가 의심되는 코드가 실행되기를 기다립니다. 경쟁 상태가 발생할 위험을 줄이고자 둘 다 결합해 사용할 수 있습니다.

• 경쟁상태 여러 프로세스가 공유 데이터를 동시에 접근할 때 공유 데이터에 대한 실행순서에 따라 실행 결과가 달라지는 상황 임계 구역 critical section이라는 작은 명령어 집합이 순서대로 실행되지 않을 때만 발생한다 경쟁상태 해결을 위해서는 동기화 매커니즘을 도입하여야한다!

  → 모든 가능한 인터리빙에 주어진 순서를 따르게 한다.

✅ 데이터 경쟁과 경쟁상태의 차이점

데이터 경쟁이 존재한다.

• 일부 인터리빙이 공유 상태와 관련된 데이터 무결성에 대한 제약 조건을 위반할 때, 공유 상태에 대한 데이터 경쟁이 존재한다고 합니다.
• 데이터 경쟁이 발생하려면 서로 다른 작업 간에 공유 상태가 있어야 하고, 그 공유 상태는 반드시 최소한 하나 이상의 작업이 수정(작성)할 수 있어야 하여 데이터 무결성을 훼손할 수 있게된다

코드 박스 14-7 [예제 14-5] 읽기 전용 공유 상태가 있는 동시 시스템

동시 시스템 {

공유 상태 {
X: 정수(읽기 전용)=5
}

작업 P{
A: 정수
1.1. A = X
1.2. A = A + 1
1.3. A를 출력
}

작업 0{
2.1. X를 출력
}

작업 R{
B: 정수
3.1. B = X + 1
3.2. B=B+ 1
3.3. B를 출력
}
}

• 이 [예제 14-5]에서 불변 제약 조건이 X에 대한 데이터 무결성을 유지하고 5, 6, 7을 출력하는 것이 라고 가정합시다.
• 서로 다른 print 명령어 사이에는 엄격한 순서가 필요하므로 경쟁 상태가 생깁니다.
• 하지만 공유 변수가 읽기 전용이므로 데이터 경쟁은 없습니다. 참고로 명령어 1.2와 3.2는 자 신의 지역 변수만을 수정할 수 있으며, 따라서 공유 상태를 수정한다고 볼 수는 없습니다.

✅ 데이터 무결성

• 데이터 무결성이란 간단히 말해 모든 작업이 언제나 공유 상태의 최신값을 읽을 수 있어야 한다는 의미입니다.
• 즉, 공유 상태를 계속 해서 수정하기 전에 공유 상태의 업데이트 내역을 인지할 수 있어야 합니다.

[코드 박스 14-6]에 보이는 [예제 14-4]는 데이터 무결성 제약 조건을 설명합니다.

동시 시스템 {
공유 상태 {
X: 정수=2
}
}
작업 P{
A: 정수
1.1. A = X
1.2. A = A+ 1
1.3. X = A
}
작업Q{
}
B: 정수
2.1. B = X
2.2. B = B+3
2.3. X = B
}
}

1. 다음 인터리빙을 고려해봅시다. 먼저 명령어 1.1이 실행됩니다.
2. 따라서 X에 대한 값은 지역 변수 A로 복제됩니다.
3. 하지만 작업 P가 그리 운이 좋지 못해서 문맥 교환이 발생하고 CPU는 작업 Q에 할당됩니다.
4. 이어서 명령어 2.1이 실행되며 X에 대한 값은 지역 변수 B로 복제됩니다.
5. 그러므로 변수 A와 B는 모두 같은 값인 2를 갖습니다.
6. 이제 작업 Q는 운 좋게도 실행을 계속할 수 있습니다. 그다음 명령어 2.2가 실행되며 B는 5가 됩니다.
7. 계속해서 작업 Q는 5를 공유 상태 X에 작성합니다. 따라서 X는 5가 됩니다.
8. 이제 다음 문맥 교환이 발생하고, CPU는 다시 작업 P에 할당됩니다. 이어서 명령어 1.2를 수행합니다. 이 지점이 바로 무결성 제약을 놓친 곳입니다. —→P가 이전의 2값을 사용!

데이터 무결성 제약 조건을 충족시키려면 명령어 1.1이 명령어 2.3 바로 뒤에 실행될 수 있도록 하거나, 명령어 2.1이 명령어 1.3 직후에만 실행되도록 해야 합니다.

⭐ 14.3 동기화 이후 문제 - CH

✅ 본질적인 동시성 관련 문제 (intrinsic concurrency-related issues)

✅ 새로운 고유한 문제 : 여러 프로세스/쓰레드가 동시에 데이터를 조작 접근을 하는 경우

• 제어 매커니즘을 적용한 결과 다른 경쟁 상태나 데이터 경쟁이 일어나는 현상 (고유적인 문제)
• 1개의 객체가 2개의 쓰레드를 접근 하는 경우 (having different race conditions or data races. Control)
  • 새로운 인터리빙을 도입하면서 생기는 경우
  • 새로운 경쟁 상태나 데이터 경쟁이 발생한 결과
  • 해결법 : 동기화 기술을 프로그램의 로직에 따라 살피고 조정

✅ 기아 상태 (Starvation): 동시 시스템에 있는 작업이 오랫동안 공유 자원에 접근하지 못하는 경우

• 특정 프로세스가 수행 가능 상태임에도 불구하고, 매우 오랜 시간동안 스케줄링 되지 못한 경우 다른 작업이 기아 상태인 작업에 의존한다면 다른 작업 역시 기아 상태가 됩니다.

✅ 교착 상태 (Deadlock):동시에 시스탬의 모든 작업이 서로를 대기하느라 모든 작업이 진행되지 않는 경우** (최악의 경우이다.)**

• 특정 프로세스가 수행 가능 상태임에도 불구하고, 매우 오랜 시간동안 스케줄링 되지 못한 경우 여러 프로세스가 동일한 자원 점유를 요청할 때 발생 (시스탬 혼수상태와 같은 상황이 된다.)
• 다른 작업이 공유 자원이나 잠긴 객체를 해제하기를 기다리면서 무한 루프에 빠지게 되면서 발생합니다.
• 반교착 상태 (semi-deadlock) :작업 중 일부, 하나 또는 두 개의 작업만 멈춰 있고 다른 작업은 계속할 수 있는 상황도 종종 있습니다.

✅ 우선순위 역전:동기화 기술을 도입한 이후, 공유 자원을 사용할 더 높은 권한을 갖는 작업이 우선순위가 낮은 작업 뒤로 블로킹될 경우

• 우선순위 역전priority inversion이 발생합니다. 잘못 구현된 동기화 기술 때문에 발생할 수 있는 부수적인 또 다른 문제에 해당합니다.
• 기아 상태는 기본적으로 운영체제의 공정 작업에서 문제를 해결해준다.
• 하지만 기아 상태는 개발자의 매커니즘으로 인해 발생한다. (데이터의 경쟁이 일어나지 않도록 인터럽트 걸어주거나 서로에게 잠금을 넣어준다)
• 대부분의 교착 상태는 특정 프로세스/쓰레드 작업에 서로가 잠금을 풀어주기를 기다리는 방식으로 해결하는 경우가 많다
• 일반적으로 기아상태보다 교착 상태가 더 많이 일어난다고 합니다.

⭐ 14.4 동기화 기술 - CH

✅ Intrinsic concurrency issues (본질적인 동기화 문제점) 경쟁상태 극복 기술

• 각각 고유 불변의 제약조건이 있으며 (제어 메커니즘의 일부 인터리빙이 시스템에서 일어나는 문제)
• 공유데이터의 일관성을 유지하기 위해 하나의 프로세스/스레드만 진입해서 실행가능한 영역이 되는 현상을 유지하기 위해 각각의 제약 조건에 대해 설명 중이다.
• 참고 : 동기화 기술을 도입하려면 새로운 코드를 작성하고 기본에 코드를 변경해야한다.
• happens-before constraints(발생 전 제약) : 코어 1개 » 프로세서 1» 쓰래드를 관리하는 관점

1. 고유한 동시성 문제 해결 방법 중 명령어의 순서를 변경해서 발생전 제약(명형어)을 부과하고 불변의 제약조건을 만족해 문제를 해결했습니다.

1. 기존에 코들의 순서를 변경하지 않고 해결하는 방법은 명령어 간에 특정한 순서를 부여하는 방법 (새로운 인터리밍을 통해 완전히 새로운 동시 시스탬 생성을 통한 해결방법이 있다.)

1. happens-before constraints(발생 전 제약) : 새로운 인터리밍을 통해 문제가 생기기 전에 제약(명령어)를 주어서 문제해결 유일한 개체 시스탬 추가해야함 (동기하 이후에 문제 해결 방법)

• 새로운 동시 시스템이란 새로운 다른 문제가 있다는 의미입니다. (직접적인 동시 시스템이었습니다.)
• 프로세서가 여러개 혹은 여러 동시 시스탬이 존재하는 경우 많은 문제가 발생한다.
• 작업 스케줄러가 문맥 교환을 수행하는 유일한 개체인 자연적인 natural 다. (작업에 원시적인 값을 넣어서 문맥 교환시 원시적인 값을 주어 해결하는 방법을 설명할 것이다.)
• 하지만 새로운 동시 시스템에서는 작업 스케줄러뿐만 아니라, 인간의 손이 닿은 인공적인 artificial 동시 시스템과 마주하게 됩니다.
• 여러 작업을 동기화하고 이 작업들을 특정 순서에 따르도록 하기에 알맞은 동기화 기술을 도입 하는 일은 직접적인 동시 환경에 달려 있습니다.
• 예를 들면 멀티프로세싱 프로그램에서 사용된 제어 메커니즘은 멀티스레딩 프로그램에서 사용된 방식과는 다를 수 있습니다.
• 구현 방식과 관계없이 모든 동시 시스템에서 가능한 추상적인 방식으로 이 메커니즘을 설명하겠습니다. 따라서 다음 기술과 개념은 모든 동시 시스템에서 유효합니다. 하지만 그 구현은 주변 환경과 시스템 자체의 실제 속성에 따라 크게 다를 수 있습니다.

✅ 스핀락 (바쁜대기)

• 바쁜대기 알고리즘
• 스핀락
  • 락을 가질수 있도록 반복해서 시도 임계 구역에 접근 권환을 얻는 것
• 스핀락의 방법
  • 공유데이터의 일관성을 유지하기 위해 하나의 프로세스/스레드만 집입해서 실행가능한 영역이 되는 현상을 목표로 명령어의 순서를 작성
  • 일반적인 해결 방법으로 한 작업의 명령어가 다른 작업의 다른 명령어 이후에 실행되도록 하기위해, 해당 작업은 후속 작업이 명령어를 실행하도록 대기해야 합니다.
  • 동시에 이 작업은 문맥 교환을 통해 CPU를 얻게될 수도 있지만 실행되지 않은 채 대기해야 합니다. 즉, 해당 작업은 후속 작업이 명령어를 실행할 때까지는 멈춰서 대기해야 합니다.
  • 후속 작업이 명령어에 대한 실행을 완료할 수 있을 때 비로소 두 가지 선택을 할 수 있습니다.
  • 이전 작업은 후속 작업이 완료되었는지 다시 한번 확인하거나, 또는 후속 작업이 이전 작업에 대해 이제 명령어를 계속해서 실행해도 된다고 알릴 수 있습니다.
  • 제어 메커니즘에서 일어나는 현상을 고려하면서 스핀락을 사용하여 일반적인 해결방법을 제시합니다.

14-8 코드 (제어 메커니즘 도입 이전의 동시 시스탬)

Concurrent System
{
	Task P
	{
		1.1. print 'A'
	}
	Task Q
	{
		2.1. print 'B'
	}
}

14-9 코드 바쁜 대기를 이용하는 해결 방법

Concurrent System
{

	Shared State // 공유 상태 // 락을 가질수 있도록 만들어준 조건 0과1
	{
		Done : Boolean = False  // 락을 가지는 조건 : 불리언

	} //빠저 나가면서 1.1은 2.2 명령어 이전에 실행

	Task P // a가 출력 될때마다 참으로 설정 1.2 참으로 설정
	{
		1.1. print 'A'
		1.2. Done = True
	}
	Task Q
	{
		2.1. 완료되지 않는 동안 아무것도 하지 않음 //
		2.2. print 'B'
	}
}

• 작업을 동기화하기 위해 명령어를 더 추가해야 했습니다. 따라서 새로운 인터리빙이 더 추가된 것처럼 보입니다. 더 정확하게 말하면, 이전과 비교해 완전히 새로운 동시 시스템을 마주한 것입니다.
• 이 새로운 시스템은 이전 시스템의 인터리빙과 비교가 되지 않는 고유한 인터리빙의 집합을 갖습니다.
• 상태가 참이 될 때까지 바쁜 대기에서 계속 모니터링 (풀링)한 다음 바쁜 대기를 빠져나갑니다.

⭐ 14.4.2 잠자기/알림 메커니즘

• 잠금은 쉽게 말해 객체 또는 변수이며, 상태가 충족되거나 이벤트가 발생하기를 기다리고자 사용합니다.
• 앞 절에서 다룬 대로 바쁜 대기 루프를 이용하는 대신, 다른 시나리오도 상상해볼 수 있습니다.
• 작업 Q는 완료 플래그에서 바쁜 대기를 하는 대신 잠들 수 있으며, 작업 P는 플래그를 참으로 만들 때 플래그의 변경에 대해 작업 Q에 알릴 수 있습니다.
• 즉, 작업 Q는 플래그가 참이 아님을 알자마자 잠자기에 들어가며 작업 P가 CPU 코어를 더 빨리 얻도록 해서 로직을 실행하게 합니다. 그 결과 작업 P는 플래그를 참으로 수정한 다음 작업 Q를 깨웁니다.

14-10잠자기 알림을 사용하는 해결법

Concurrent System
{

	Task P
	{
		1.1. print 'A' //
		1.2. Notify Task Q // CPU 점유하지 않음 a를 출력시 알림 key
	} //작업 스케줄러는 잠든 작업으로 타임 슬라이스를 주지 않습니다.
	//신호 전달 signaling
	//a의 알림이 우리기 전까지 스케줄러가 큐에 넣어 잠자기 모드 실행
	Task Q // a가 출력 되면 q 가출력
	{
		2.1. Go To Sleep Mode //잠자기 모드 락을 걸어줌
		2.2. print 'B'
	}
}

• 알림 = 키
• 작업이 잠들면 이점: CPU의 시간을 낭비하지 않습니다.
• 상태를 실행 되기 위해 바쁜 대기를 시작하는 대신, 작업은 잠을 자며 상태가 충족될 때 알림을 받습니다.

14-11 : 결과 (반 교착 상태)

1.1 print 'A' //  	Task P 는 A를 출력했고
1.2. Notify Task Q // a를 출력시 알림 key
2.1. Go To Sleep Mode  //작업 Q는 CPU를 얻으면 즉시 잠들기 모드로 들어갑니다
2.2. print 'B'

14-12 잠들기 알림 접근법에 따른 개선된 해결법

Concurrent System
{
	Shared State // 락을 가질수 있도록 만들어준 조건 0과1
	{
		Done : Boolean = False
	}
	Task P
	{
		1.1. print 'A'
		1.2. Done = True
		1.3. Notify Task Q
	}
	Task Q // 여전히 p를 통해서 알림 해제를 받는다.
	{
		2.1. While Not Done { //완료가 거짓일 때만 잠듭니다.
		2.2. Go To Sleep Mode If Done is False (Atomic)// 2.2는 플래그를 체크하는 루프 안에 놓이며
		2.3. }//반드시 원자 명령어여야 한다는 점입니다.
		2.4. print 'B'
	}
}

/*
NOTE_ 만약 동시 시스템의 경험이 있다면, 이 명령어가 원자적이라고 했을 때 약간 놀랄 수도 있습니다.
그 주요 이유는 앞의 예제에서 명확한 임계 구역을 정의하고 임계 구역을 뮤텍스mutex를 사용해
보호할 때만 진정으로 체감할 수 있는 동기화가 발생하기 때문입니다. 진도를 나가면서 더 명확해질 것
이며, 더 개념적인 주제를 다룬 뒤에야 실질적인 해결책을 살펴볼 수 있습니다.

*/

• 반 교착 상태 (책에서 말하는) (세미 데드락)
  • 작업 1은 일을 하는데 작업 2는 영원히 잠을 자버리는 현상
• 락을 가지면서 알림을 이용하는 방법
  • 키를 따로 갖지 객체(함수) 또는 변수로 주지 않은 상태
  • 1명의 키를 가지고 1명이 일을 마치면 일을 마친 사람이 알림을 해주는 형태
  • 잠든 작업은 작업 P뿐만 아니라 시스템의 무언가에 의해 알림을 받으므로 루프가 필요합니다.
  • 실제 시스템에서 운영체제나 다른 작업은 한 작업에 알림을 줄 수 있습니다. 하지만 여기에서는 작업 P가 받는 알림만 살펴봅니다.

⭐ 4.4.3 세마포어와 뮤텍스

• 세마포어: Signaling mechanism. 현재 공유자원에 접근할 수 있는 쓰레드, 프로세스의 수를 나타내는 값을 두어 상호배제를 달성하는 기법

• 뮤텍스 : 한번에 1개의 작업만 임계구역으로 들어가는 세마포어

  • 공유 자원에 대한 접근을 동기화할 때 사용하는 변수 또는 객체입니다.

  • 뮤텍스로 데이터 경쟁이 없는 상호 배제 기반으로 문제 해결

    1. 언제든 작업 중 하나만 임계 구역에 들어갈 수 있으며, 다른 작업은 이 작업이 임계 구역을 떠날 때까지 기다려야 됩니다.

    2. 해결 방법에는 교착 상태가 없어야 합니다. 임계구역에 입장하기를 기다리는 작업은 결국 들어갈 수 있어야 합니다.
    3. 임계구역에 있는 작업은 다른 작업이 임계구역이 들어가기 위해 선점해 배낼수 없습니다.

  • 세마 포어로 데이터 경쟁이 없는 상호 배제 기반으로 문제 해결

    1. 언제든 작업 중 하나만 임계 구역에 들어갈 수 있으며, 다른 작업은 이 작업이 임계 구역을 떠날 때까지 기다려야 됩니다.

    2. 해결 방법에는 교착 상태가 없어야 합니다. 임계구역에 입장하기를 기다리는 작업은 결국 들어갈 수 있어야 합니다.
    3. 임계구역에 한번에 두개이상의 작업이 들어갈수 있습니다.
• 뮤택스
  • 하나의 작업만 임계 구역에 있도록 하며, 세마포어와 비슷하게 잠금과 해제는 메모리 장벽으로 작용할 수 있습니다.

코드 예제

Concurrent System {

	 Shared State { // 세마 포어 생성
	 S : Semaphore which allows only 1 task at a time
	 Counter: Integer = 0
	 }

	 Task P {
		 A : Local Integer
		 1.1. EnterCriticalSection(S) // 임계구역 진입
		 1.2. A = Counter
		 1.3. A = A + 1
		1.4. Counter = A
		1.5. LeaveCriticalSection(S) // 임계구역 떠나기
	 }
	 Task Q {
		 B : Local Integer
		 2.1. EnterCriticalSection(S) // 임계구역 진입
		 2.2. B = Counter
		 2.3. B = B + 2
		 2.4. Counter = B
		 2.5. LeaveCriticalSection(S) //임계구역 떠나기
	 }
}

중요 포인트

	 Shared State { // 세마 포어 생성
	 S : Semaphore which allows only 1 task at a time
	 Counter: Integer = 0
	 }

//세마포어를 기다리는 행위와 임계 구역에 입장하는 행위는 세마포어 잠금 lock과 같습니다.
//세마포어를 떠나거나 세마포어를 업데이트하는 것 역시 세마포어 잠금 해제unlock와 같습니다.

	 Task P {
		 A : Local Integer
		 1.1. EnterCriticalSection(S) // 임계구역 진입
		 1.2. A = Counter
		 1.3. A = A + 1
		1.4. Counter = A
		1.5. LeaveCriticalSection(S) // 임계구역 떠나기
	 }

• 임계구역을 직접 지정해줌으로 대기중인 작업을 락을 걸어줄 수 있습니다.
• 세마포어 S는 하나의 작업만이 임계 구역에 들어갈 수 있도록 사용되었습니다.
• 세마포어는 보통 이진 세마포어 binary semaphore 또는 뮤텍스라고 합니다. 뮤텍스는 세마포어보다 훨씬 더 일반적이며 동시적인 코드에서 항상 볼 수 있습니다.

• 경쟁 상태가 없는 상호 배제 상태가 됩니다.

  1. 언제든 작업 중 하나만 임계 구역에 들어갈 수 있으며, 다른 작업은 이 작업이 임계 구역을 떠날 때까지기다려야 합니다.

  2. 해결 방법에는 교착 상태가 없어야 합니다. 임계 구역에 입장하기를 기다리는 작업은 결국 들어갈 수 있어야 합니다. 때에 따라서는 대기 시간의 상한선(경합 시간contention time)을 정합니다.
  3. 임계 구역에 있는 작업은 다른 작업이 임계 구역이 들어가기 위해 선점preemption해 빼낼 수 없습니다.
• 즉, 이 해결 방안은 선점이 없어야 하고 preemption free 협조적 collaborative 이어야 합니다.
• 세마포어와 뮤텍스는 잠글 수 있는 객체라고 합니다.
• 세마포어의 잠금과 해제는 각각 임계 구역에 대한 대기 및 접근 획득, 임계 구역 해제에 사용되는 두 가지 알고리듬이라고 볼 수 있습니다.

Concurrent System {

 Shared State {// 공유상태
 S : Semaphore which allows only 1 task at a time//한번에 하나의 작업을 허용하는 세마포어
 Counter: Integer = 0
 }

Task P {
	 A : Local Integer
	 1.1. Lock(S) // 세마포어 / 뮤텍스 잠금
	 1.2. A = Counter
	 1.3. A = A + 1
	 1.4. Counter = A
	 1.5. Unlock(S)// 세마포어 / 뮤텍스는 해제
 }
 Task Q {
	 B : Local Integer
	 2.1. Lock(S)
	 2.2. B = Counter
	 2.3. B = B + 2
	 2.4. Counter = B
	 2.5. Unlock(S)
 }
}

✅ 시나리오

• 이제 이를 동시 컴퓨터 시스템과 연결해 세마포어가 이러한 비유 속의 비서와 같은 일을 하는지 알아봅시다.
• 예시에서 의사는 공유 자원입니다. 여러 환자는 의사에게 접근할 수 있는데, 이는 공유 자원에 접근하려는 작업과 비슷합니다.
• 비서는 세마포어입니다. 목록을 가진 비서처럼, 각 세마포어는 공유 자원에 대한 접근을 획득하기 위해 대기하는 작업 대기열이 있습니다.
• 진료실은 임계 구역이라고 볼 수 있습니다.
• 임계 구역이란 세마포어가 보호하는 간단한 명령어 집합입니다.
• 작업은 세마포어 뒤에서 기다리지 않고서는 임계 구역에 들어갈 수 없습니다.
• 반면 임계 구역을 보호하는 것이 세마포어의 역할입니다. 작업이 임계 구역에 들어가려고 할 때마다 특정 세마포어에 알려야 합니다.
• 마찬가지로 작업이 완료되고 임계 구역에서 나가려 할 때 작업은 동일한 세마포어에 이를 알려야 합니다.

⭐ 14.4.4 멀티프로세서 유닛

• 멀티프로세서 유닛이란
  • 두 개 이상의 코어가 있는 CPU 또는 코어의 수와 상관없이 CPU가 여러 개인 것을 의미합니다.

• 멀티 프로세서 유닛의 리스크

  • CPU 코어에서 실행되고 메인 메모리의 같은 주소에서 작업할 때 멀티 프로세서 유닛의 리스크 발생

  → CPU 코어에서 실행되고 메인 메모리의 같은 주소에서 작업할 때

• 멀티 프로세서 유닛의 리스크를 발생하는 이유
  • CPU 코어는 자신의 지역 캐시에 같은 메모리 주소값을 저장합니다.
  • 만약 한 작업이 공유된 메모리 주소에 쓰기 작업을 할 때는 지역 캐시에만 변경 사항이 적용되며, 메인 메모리나 다른 CPU 코어의 지역 캐시에는 적용되지 않는다.
• 최신 값을 읽으려 할 때, 이 작업들은 최신 값을 갖지 않은 자신의 지역 캐시에서 읽으려고 하므로 최신 값을 알 수 없기 때문입니다.
• 메모리 일관성 프로토콜 memory coherence protocol을 도입해 해결합니다.
• 동시 시스탬에서 고려해야할 두가지 요인
  • 메모리 일관성 도입시 cpu 코어 중 하나의 값을 변경할 때 자신들의 지역캐시에서 같은 값을 볼 수 있다.
  • 해결방안으로 메모리 가시성을 도입하여 해결

예시 14-6 에서 불변의 조건 a를 먼저출력하고 b를 출력해라 했을때 원하는 순서대로 실행하는 잠자기 / 알림

Concurrent System
{
	Shared State
	{
		Done : Boolean = False
	}
	Task P {
		1.1. print 'A'
		1.2. Done = True
		1.3. Memory Barrier
		1.4. Notify Task Q
	}
	Task Q {
		2.1. Do {
		2.2. Memory Barrier
		2.3. Go To Sleep Mode If Done is False (Atomic)
		2.4. } While Not Done
		2.5. print 'B'
	}
}

코드 박스 14-17 뮤텍스로 [예제 14-6]에 대한 해결 방법 향상하기

shared State
{
	Done : Boolean = False
	M : Mutex
	}
	Task P
		{
	1.1. print 'A'
	1.2. Lock(M)
	1.3. Done = True
	1.4. Unlock(M)
	1.5. Notify Task Q
		}
	Task Q
		{
	2.1. Lock(M)
	2.2. While Not Done {
	2.3. Go To Sleep Mode And Unlock(M) (Atomic)
	2.4. Lock(M)
	2.5. }
	2.6. Unlock(M)
	2.7. print 'B'
		}
}

• 하나의 작업만 임계 구역에 있도록 하며, 세마포어와 비슷하게 잠금과 해제는 메모리 장벽으로 작용할 수 있습니다.

• 뮤텍스(혹은 세마포어)를 잠글 때, 뮤텍스가 자동으로 해제되는 경우

  1. 작업이 Unlock 명령어를 사용하면 뮤텍스가 해제 됩니다.
  2. 작업이 완료되면 모든 잠긴 뮤텍스가 해제 됩니다.
  3. 작업이 잠자기 모드가 되면 잠겼던 뮤텍스가 해제 됩니다.
• 재귀적인 뮤택스 : 작업하나로 여러번을 잠글수 있다.

⭐ 14.5 스핀락

✅ 스핀락

• 쉽게말하여 바쁜 대기(spinning) 알고리듬
• 스핀락 뮤텍스를 잠글 때마다 뮤텍스를 사용할 수 있을 때까지 바쁜 대기 루프에 들어가고 나서 그다음을 계속합니다.

동시 시스템 {

공유 상태 (
완료: 불리언 = 거짓
M: 뮤텍스
}

작업 P{
1.1. 'A'를 출력
1.2. 스핀락: SpinLock(M)
1.2. 완료 =참
1.3. 스핀락 해제: SpinUnlock(M)
}

작업 Q{
2.1 스핀락: SpinLock(M)
2.2. 완료가 아닌 동안{
2.3.  스핀락 해제: SpinUnlock(M)
2.4.  스핀락: SpinLock(M)
2.5. }
2.6. 스핀락 해제: SpinUnlock(M)
2.7. 'B'를 출력
}
}

• 루프 안의 2.3 2.4 명령어들은 이상한 연속적인 잠금 및 해제 명령어입니다.

작업 Q가 CPU 코어를 가지는 동안, 스핀락 뮤텍스 M을 잠그고 해제 하는 일이 연속해서 진행 중입니다.

• 만약 명령어 2.3과 2.4가 없다면 어떻게 될까요?

명령어 2.1에서 잠금은 명령어 2.6이 될 때까지 뮤텍스가 잠긴 상태가 되도록 합니다.

→이는 작업 P가 공유 플래그 완료에 접근할 기회를 찾지 못한다는 의미입니다.

→시스템이 반교착 상태가 됩니다.

잠금과 해제 명령어는 작업 P가 접근 기회를 찾고 명령어 1.2를 통해 플래그 완료를 업데이트하도록 합니다.

✅ 조건변수

• 쉽게 말해 변수(혹은 객체)
• 작업을 잠자기 모드로 만들거나 다른 잠든 작업 에 알리고 깨울 수 있습니다.
• 여기서 잠자기는지연이 아닌 이는 작업이 더 이상 CPU 공유를 받지 않는다는 의미입니다.
• 조건 변수는 서로 다른 작업 간에 신호 전달을 하는 데 사용됩니다.
• 잠금과 해제 작업과 관련한 뮤텍스처럼 조건 변수는 잠자기 및 알림 작업이 있습니다.
• 잠자기와 알림 대신에 대기 wait와 신호signal 로도 사용

• 조건 변수는 반드시 뮤텍스와 함께 사용해야 합니다.

  → 상호 배제 mutual exclusion 속성

• 다음 [코드 박스 14-19]의 의사코드는 일반적으로 특정 조건 또는 이벤트를 기다리는 조건 변수 및 뮤텍스를 사용하는 법을 나타냅니다. 특히 [예제 14-6]에서 공유 플래그 완료가 참이 될 때까지 대기하도록 합니다.

코드 박스 14-19 [예제 14-6]에 대해 조건 변수를 사용한 해결 방법

동시 시스템 {

공유 상태 {
완료: 불리언= 거짓
CV : 조건 변수
M: 뮤텍스
}

작업 P {
1.1. 'A'를 출력
1.2. 잠금: Lock(M)
1.3. 완료 = 참
1.4. 알리기: Notify(CV)
1.5. 잠금 해제: Unlock(M)
}

작업 Q {
2.1. 잠금: Lock(M)
2.2. 완료가 아닌 동안 {
2.3. 잠자기: Sleep(M, CV)
2.4.  }
2.5. 잠금 해제: Unlock(M)
2.6. 'B'를 출력
}
}

동시 시스템에서 두 명령어 간 엄격한 순서를 구현하기 위해 조건 변수를 사용!

• 명령어 1.4와 2.3은 조건 변수 CV를 사용합니다. 작업 Sleep은 뮤텍스 M과 조건 변수 CV에 대해 둘 다 알아야 합니다.
• 작업 Q가 잠들 때는 잠금을 해제해야 하고, 작업 Q가 알림을 받았을 때는 Sleep 작업 내부에 있는 로직을 계속해서 M을 다시 잠급니다

• 명령어 1.4 또한 M에 대한 잠금을 획득했을 때만 작동하며, 잠금을 획득하지 않았다면 경쟁 상태가 발생합니다.

• 뮤텍스 객체와 조건 변수를 일반적으로 모니터 객체 monitor object라고 한다.
• 또한 동시성과 관련된 설계 패턴도 모니터 객체라고 하는 데, 어떤 동시 작업에서 명령어의 순서를 다시 정하기 위해 앞의 기술을 사용하는 것과 관련됩니다.
• 앞 절에서는 여러 개의 동시 작업에 있는 명령어 사이에서 순서를 엄격히 지키게 하고 임계구역을 보호하기 위해 세마포어, 뮤텍스, 조건 변수 및 잠금 해제, 잠자기, 알림 알고리듬을 사용 하는 방식을 보여줬습니다.

⭐ 14.6 POSIX의 동시성

✅ POSIX의 동시성

• POSIX 호환 운영체제의 동시성은 일반적으로 두 가지 방식으로 제공됩니다. 동시 프로그램은
• 멀티프로세싱 multiprocessing이라고 하는 서로 다른 프로세스로 실행하거나
• 멀티스레딩 multithreading이 라고 하는 동일한 프로세스에 있는 서로 다른 스레드로 실행할 수 있습니다.

✅ 동시성을 지원하는 커널

• 모든 커널은 실행 중인 여러 프로세스 및 스레드사이 에서 CPU 코어를 공유하는 작업 스케줄러 유닛task scheduler unit이 있습니다.

• 프로세스와 스레드가 무엇인지 동시성 측면에서 차이점은?

  • 프로세스 프로그램을 실행할 때마다 새 프로세스가 생성되고, 프로그램 로직은 해당 프로세스 내부에서 실행됩니다. 프로세스는 서로 떨어져 있으며, 마치 메모리처럼 한 프로세스는 다른 프로세스로 접근할 수 없습니다.
  • 스레드 스레드는 프로세스와 매우 유사하지만, 특정 프로세스에 국한합니다. 스레드는 동시적인 방식으로 여러 명령어를 함께 실행하는 여러 실행 스레드를 이용해 단일 프로세스에 동시성을 도입 합니다. 단일 스레드는 두 프로세스 간에 공유될 수 없으며, 스레드를 소유한 프로세스에 국한 되어 바인딩됩니다. 스레드는 프로세스안에 여러 개 존재가능하다! 커널 수준에서 이야기할 때는 스레드나 프로세스라는 용어 대신 작업 ask
• 한 프로세스의 모든 스레드는 공유 자원으로써 자신들을 소유한 프로세스의 메모리에 접근할 수 있습니다.
• 모든 스레드에는 같은 주소에 있는 다른 스레드가 접근할 수 있는 스택 영역이 존재합니다
• 게다가 프로세스와 스레드는 모두 CPU를 공유할 수 있으며, 대부분 의 커널에 있는 작업 스케줄러는 이들 사이에 CPU 코어를 공유하는 같은 스케줄링 알고리듬을 사용합니다.

✅ 스케줄링 알고리듬 종류

• 비선점 스케줄링 cooperative scheduling

  • 작업에 CPU 코어를 부여하고 협력 작업이 CPU 코어를 해제하기를 대기하는 것입니다.
  • 작업에서 CPU를 회수하는 강제력이 없다 → 선점적 preemptive이지 않습니다.

• 선점 스케줄링 preemptive scheduling

  • 스케줄러 가 CPU 코어를 회수할 때까지 작업이 CPU 코어를 사용할 수 있습니다.
  • 스케줄러가 선점을 통해 CPU를 회수하려면 우선순 위가 높은 선점 신호preemptive signal가 있어야 합니다
  • 특정 유형의 선점 스케줄링에서는 작업이 특정 시간 동안 주어진 CPU 코어를 사용가능
    • 이러한 유형의 선점 스케줄링을 시분할이라고 하며, 현재 커널에서 가장 많이 사용되는 스케줄링 전략입니다. CPU를 사용하기 위해 작업에 주어지는 시간 간격에는 다양한 이름이 있는데, 여러 학술 문헌 에서 타임슬라이스, 타임 슬롯time slot, 또는 양자화 quantum라고 합니다.

⭐ 14.7 멀티프로세싱

✅ 멀티 프로세싱

• 간단하게는 동시 작업을 하는 프로세스를 사용한다는 의미
  • EX) 공용 게이트웨이 인터페이스 common gateway interface (CGI)
• 프로세서들은 소프트웨어가 계속 기능하도록 필수 정보를 공유해야 합니다

✅ 프로세서 간 공유 상태에 접근할 때 사용할 수 있는 기술

• 파일 시스템 file system: 프로세스 사이에서 데이터를 공유하는 가장 간단한 방식으로 볼 수 있습니다.
  • 이 접근법은 아주 오래되었으며 거의 모든 운영체제에서 지원합니다.
  • 한 가지 예는 소프트웨어 프로젝트에 서 많은 프로세스가 읽는 구성 파일 configuration file입니다.
  • 만약 프로세스 중 하나가 파일을 읽으려고 한 다면, 데이터 경쟁 및 동시성 관련 문제를 방지하기 위해 동기화 기법을 사용해야 합니다.
• 메모리 맵 파일 memory-mapped file: 모든 POSIX 호환 운영체제 및 마이크로소프트 윈도우에서는 디스크에 있는 파일에 매핑되는 메모리 영역이 있습니다.
  • 이 메모리 영역을 읽거나 수정할 수 있는 여러 프로세 스 사이에 해당 영역을 공유할 수 있습니다.
  • 이 기술은 파일 시스템 접근법과 매우 비슷하지만, 파일 API 를 사용하는 파일 서술자로부터 데이터를 스트리밍할 때 발생하는 골칫거리는 적습니다.
  • 매핑된 영역에 대한 접근 권한이 있는 프로세스가 이 영역의 내용을 수정할 수 있을 때, 적절한 동기화 메커니즘을 사용 해야합니다.
• 네트워크 network: 다른 컴퓨터에 있는 프로세스들이 통신하는 유일한 방법은 네트워크 인프라 및 소켓 프로그래밍 API를 사용하는 것입니다.
  • 소켓 프로그래밍 API는 SUS 및 POSIX 표준에서 중요하며, 거 의 모든 운영체제에 있습니다.
  • 이 기술에 대한 세부적인 내용은 너무 방대하고 이를 다루는 책도 많습니다.
• 신호 signal: 같은 운영체제 내에서 실행되는 프로세스는 서로 신호를 보낼 수 있습니다.
  • 이는 명령 신호를 전달할 때 많이 쓰이지만, 작은 상태(페이로드payload)를 공유할 때도 쓰일 수 있습니다.
    • 공유 상태의 값 은 신호로 전달할 수 있으며 대상 프로세스에서 가로챌 수 있습니다.
• 공유 메모리 shared memory: POSIX 호환 운영체제 및 마이크로소프트 윈도우에서는 여러 프로세스 사이에 공유되는 메모리 영역이 있습니다.
  • 그러므로 프로세스들은 이 공유 영역을 사용해 변수를 저장하고 값을 공유할 수 있습니다.
    • 공유 메모리는 데이터 경쟁으로부터 보호되지 않으며, 따라서 수정 가능한 공 유상태에 대한 자리 표시자로 공유 메모리를 사용하려는 프로세스는 동시성 문제를 피하기 위한 동기화 메커니즘을 사용해야 합니다.
    • 공유 메모리 영역은 동시에 여러 프로세스가 사용할 수 있습니다.
• 파이프 pipe: POSIX 호환 운영체제 및 마이크로소프트 윈도우에서 파이프는 단방향 통신 채널입니다.
  • 파이프는 두 프로세스 간에 공유 상태를 전송할 때 사용할 수 있습니다. 한 프로세스는 파이프를 작성하고 다른 하나는 파이프로부터 읽습니다.
  • 파이프는 기명 또는 익명일 수 있으며, 각 파이프는 고유한 유스 케이스가 있습니다.
• 유닉스 도메인 소켓 Unix domain socket: POSIX 호환 운영체제 및 최근의 윈도우 10에는 유닉스 소켓이라는 통신 단말이 있습니다.
  • 동일한 머신에 있고 동일한 운영체제 내에서 실행되는 프로세스들은 유닉스 도메인 소켓을 사용해서 전이중 채널 full-duplex channel을 통해 정보를 전달할 수 있습니다.
  • 유닉스 도메인 소켓은 네트워크 소켓과 매우 비슷하지만, 모든 데이터는 커널을 통해 전송되며 따라서 소켓은 데이터를 전송하는 아주 빠른 방식을 제공합니다.
  • 멀티프로세스는 공유 데이터를 통신하기 위해 같은 유닉스 도메인 소켓을 사용할 수 있습니다.
  • 유닉스 도메인 소켓 또한 동일한 머신에 있는 프로세스 간 파일 서술자를 전송하는 등의 특이한 유스케이스에도 사용될 수 있습니다.
  • 유닉스 도메인 소켓의 좋은 점은 네트워크 소켓인 것처럼 동일한 소켓 프로그래밍 API를 사용해야 한다는 점입니다.
• 메시지 대기열 message queue: 메시지 대기열은 거의 모든 운영체제에 있습니다.
  • 메시지 대기열은 많은 메시지를 송수신하는 여러 프로세스가 사용하는 커널에서 유지 관리합니다.
  • 프로세스는 서로에 대해 알 필요가 없으며, 메시지 대기열에 대한 접근 권한만 있으면 충분합니다.
  • 이 기술은 동일한 머신에 있는 프로세스가 서로 통신할 수 있도록 할 때만 쓰입니다.

• 환경 변수 environment variable: 유닉스 계열 운영체제 및 마이크로소프트 윈도우는 운영체제 자체에서 보 관하는 일련의 변수를 제공합니다.

  • 이러한 변수를 환경 변수라고 하며, 환경 변수는 시스템 내의 프로세 스에 접근할 수 있습니다.
• 여러 스레드 및 프로세스를 동기화하는 제어 기술에 관해, 멀티프로세싱과 멀티스레딩 환경에서 쓰이는 기술이 POSIX 표준이 제공하는 것과 매우 유사한 API를 공유한다는 점을 알게 될 것입니다.
• 하지만 뮤텍스나 조건 변수에 대한 기본 구현은 멀티스레딩과 멀티프로세싱 사용에 서 서로 다를 수 있습니다. 자세한 예는 다음 15장에서 제공하겠습니다.

⭐ 14.8 멀티스레딩

✅ 멀티 스레딩

• 멀티스레딩은 동시 환경에서 병렬 작업을 수행하기 위해 사용자 스레드를 이용하는 것입니다.
• 각 프로세스는 최소한 하나의 스레드를 가지는데 이를 메인 스레드 main thread라고 합니다.
• 단일 스레드를 사용해 모든 작업을 수행하는 프로그램은 단일 스레드single-threaded 프로그램
• 프로세스 내의 모든 스레드는 같은 메모리 영역에 접근 할 수 있습니다. (변수 선언하여 메모리사용)
• 스레드는 프로세스와 매우 비슷한 만큼, 프로세스가 상태를 공유하거나 전송할 때 사용하는 모 든 기술을 사용할 수 있습니다.

✅ 멀티프로세스와 멀티스레딩의 차이점

• 멀티프로세싱과 멀티스레딩 간에 프로세스나 스레드가 중간에 공유 상태 없이 작동하는 한,그리 큰 차이는 없습니다. 스레드 대신 프로세스를 사용할 수 있으며 그 반대도 가능합니다.

• 한 가지 차이점은 사용 가능한 동기화 기술에 있습니다. 이러한 메커니즘이 사용하도록 제공하는 API는 거의 같지만, 멀티프로세스 환경에서 작동하는 것은 훨씬 더 복잡하며 기본 구현도 다릅니다.

• 멀티프로세싱과 멀티스레딩 사이의 또 다른 차이는 공유 상태를 사용하는 기술에 있습니다. 프로세스에 사용할 수 있는 기술을 스레드도 모두 사용할 수 있는 한편, 스레드는 같은 메모리 영역을 사용해서 상태를 공유할 수 있다는 장점이 있습니다.

• 더 자세히 설명하면, 프로세스는 전용 메모리를 갖습니다. 그리고 다른 프로세스는 이를 읽거나 수정할 수 없습니다. 하지만 스레드에는 훨씬 쉬운 일입니다. 같은 프로세스 내의 모든 스레드는 같은 프로세스의 메모리에 접근할 수 있습니다. 그러므로 스레드들은 공유 상태를 저장하 기 위해 같은 프로세스의 메모리를 사용할 수 있습니다.