this->OS.code(5)

다수의 thread가 concurrent하게 실행 => thread 충돌문제 발생이 가능하다.

cf. single thread의 경우, process 충돌이라고도 부른다.

 

<핵심용어>

- race condition: 2개 이상의 process가 같은 메모리를 거의 동시에 접근(access)할 때 값을 바꾸는 것을 예측할 수 없는 경우

- mutual exclusion: 2개 이상의 process가 같은 메모리를 거의 동시에 접근할 때 한번에 한 process씩 접근하게 함(상호배척)

- critical section: 다른 process와 공유하는 메모리(resource)를 접근하게 하는 코드

- starvation: 자원이 배정되지 않고 오래 기다리는 상태

- deadlock: 영원이 자원이 배정되지 않는 상태(starvation이 지속)

 

mutual exclusion이 보장되게 critical section을 잘 짜서 race condition이 발생 안하게 해야함

 

 

<Race condition>: cpu가 여러개가 아닌 1개일 때도 발생가능

producer process와 consumer process끼리 정보전달을 위해서 IPC를 이용해야 함

=> IPC(shared memory)를 사용할 때 충돌(race condition)이 발생가능하다.

 

 

 

 

<processor가 1개일 때의 Race condition>

load: register를 불러옴

store: 증가시킨 register값을 critical section(counter)에 저장

 

 

<Interrupt>: 컴퓨터 하드웨어 장치가 cpu에게 event 발생을 알리는 방법

 

 

- interrupt가 걸릴 수 있는 곳을 왼쪽에 표시한 것. (2번째에서 interrupt가 걸린것)

interrupt 종류에 따라 바뀔 수 있고 위의 그림은 producer->consumer로 바뀐 것.

 

- Multi threading의 경우에도 global variable에 race condition이 발생가능

(따라서 하나의 process에서 여러 thread를 사용해도 race condition이 발생가능)

 

<race condition을 어떻게 막을 수 있을까?>

atomic operation: critical section을 assembly 전체를 실행

--> assembly instruction이 여러줄이면 interrupt 지연으로 문제발생이 가능

 

2. fence: critical section 주변에 fence를 만들기

--> mutual exclusion보장 가능하며 실행동안 interrupt가 걸리기에 context switch가

가능하다 (atomic operation이 아님).

 

 

<Three Requires: critical-section>- 아래 3가지 모두를 만족해야 한다.

Mutual Exclusion: 하나를 실행중일 때 다른 process 실행X

Progress: 아무도 공유data를 접근하지 않을 때, 나의 critical section data를 진행해서 공유 data를 쓸 수 있어야 한다.

Bounded Waiting: 누가 공유data에 접근해있고, 기다릴 때 그 시간이 정해져 있다.

 

<Software Solution>- code 설계하는 법 

 

 

[software solution-1]

if가 아닌 P0가 아닌 P1이 먼저 실행되면

P1은 while문에 걸려 fence 안으로 들어갈 수 없다.

 

 

[software solution-2]

- 3가지 require들을 만족한다.

- but, 3개 이상의 process에서는 만족X

 

 

[software solution-3]

- 3개 이상의 process에서도 만족

- 하지만 실용적이지 않아 사용X