contents
Concurrency Control(병행 제어)
•
프로세스가 동시에 뭔가를 실행하면서 생기는 문제를 해결
•
Concurrency 상황에서 잘 control해서 문제가 생기지 않도록 해야 함
수단 :
1.
Semaphores(일종의 추상 자료형, P(S), V(S)) → 프로그래머가 직접하기 때문에 문제 발생
Classic Problem : Bounded-Buffer Problem, Readers and Writers Problem, Dining-Philosophers Problem
2.
Monitor : 프로그래밍 언어 차원에서 공유 데이터 접근을 모니터가 자동으로 해결 → 프로그래머의 부담을 줄임, 하나의 Active Process가 돌아가도록 해주는 방식
•
접근 도중에 CPU를 빼앗겨서 또 다른 프로세스가 모니터를 접근하는 코드로 들어오려고 한다면 CPU를 뺏긴 프로세스는 모니터 안에 여전히 남아서 Active한 코드로 존재한다.
•
다른 프로세스는 모니터 안의 코드를 실행하지 못하고 Queue 기다려야만 함
•
줄 서있는 프로세스들은 안에 있는 Active한 프로세스가 0이 될 때(CPU를 얻어서 다 쓰고 나감, 내부 충족이 되지 않아서 Sleep 상태로 들어갔을 때 → inactive) 모니터 안으로 들어가서 실행될 수 있다.
•
프로그래밍 언어마다 Monitor를 어떻게 지원할지는 다 다르다. → 객체지향 프로그래밍에서 주로 사용
•
monitor에서의 condition variable : 어떤 프로세스를 잠들게 하고 줄 세우기 위한 변수
◦
wait() : 어떤 프로세스를 잠들게 하겠다
◦
signal() : 잠든 프로세스가 있다면 깨워줘라
생산자 소비자 문제 with Monitor
•
lock를 걸거나 푸는 액션 필요 없음
•
빈 버퍼가 없다면 빈 버퍼를 기다리는 줄에 가서 잠들게 한다.
•
빈 버퍼가 있다면 그 버퍼에 데이터를 채워놓고 내용이 들어있는 버퍼를 기다리면서 잠들어 있는 프로세스가 있다면 깨우기
•
condition variable
◦
full : 내용이 들어있는 버퍼를 기다리면서 잠들기, 줄 세워두기
◦
empty : 내용이 없는 버퍼를 기다리면서 잠들기, 줄 세워두기
→ 세마포어를 사용했다면, 1. 세마포어 자체에 대한 이해 / 2. P, V 연산에 대한 이해 / 3. if문이 없다
→ Monitor 코드가 프로그래머에겐 자연스럽다.
Semaphore와 비교
•
공유 데이터에 대한 lock를 해줘야 하기 때문에 lock를 나타내는 변수 존재 → 락을 건다음 접근 & 풀기
•
빈 버퍼, 내용이 들어있는 버퍼의 갯수를 세는 변수 존재(값) → Monitor에서의 Condition Variable(줄 세워서 잠들게 하기)
•
Monitor에서 잠들어 있는 프로세스가 없다면 아무일도 일어나지 않는다 → Semaphore에서는 값을 세어주는 변수의 값을 -1 하는 등의 액션이 발생
•
목적이 다르다
◦
Monitor : 동시 접근을 막는 것을 Monitor 차원에서 지원해줌
◦
Semaphore : 자원을 획득하기 위해서 프로그래머가 알아서 P, V 연산을 해주는 것
Dining Philosophers 문제 with Monitor
•
젓가락을 잡는 코드가 모니터 내부의 코드로 들어가 있음
•
state는 공유 변수이다.
◦
본인만 본인의 상태를 바꿀 수 있는 것이 아니고 인접한 철학자들도 그 사람의 상태를 바꿀 수 있기 때문에
◦
하지만, 모니터 안에서 공유 데이터를 다루는 코드를 만들어줬기 때문에 lock를 걸거나 푸는 액션이 필요없음
•
두 개 다 잡을 수가 있는지 Test하는 코드를 만들어둠
•
만약 두 개 다 잡을 수 없다면 밥 먹는 상태로 바뀌지 못했을 것 → 잠들게 된다.
•
putdown하는 코드에서는 내 인접한 철학자가 나 때문에 밥을 못 먹고 잠들어 있을 수 있기 때문에 철학자를 깨워주는 코드를 넣어준다.