유한한 버퍼의 크기
Producer
Consumer
Consumer는 Producer 프로세스와 정반대.
유한한 크기때문에 생기는 문제
synchronization 변수들
Semaphore full = 0 , empty = n, mutex = 1(하나의 프로세스만 접근하도록 lock을 위한 변수);
: procss가 DB(공유데이터)에 write중일때 다른 process가 접근하면 안됨 (lock)
read는 동시에 여럿이 가능
Solution
먼저 Reader쪽에서 쭉 읽고 그동안 Writer는 다 읽을 동안 기다린다.
10000개가 들어와 readCount가 1이 된 순간 다시 1000개가 들어온다면 또 Writer는 기다려야한다
--> Starvation문제 발생
어느정도 일정량이 지나면 Writer에게 권한을 넘겨주는 식으로 해결한다.
문제점
Deadlock : 모든 철학자가 동시에 배가 고파져 왼쪽젓가락을 든 경우
해결책
semaphore의 문제점
코딩하기 어려움
정확성입증이 어렵다
자발적 협력이 필요하다
한번의 실수가 모든 시스템에 치명적인 영향을 끼친다.
예)
V(mutex)
Critical Section
P(mutex)
Mutual Exclution 깨짐
예2)
P(mutex)
Critical Section
P(mutex)
Deadlock
High-level synchronization construct
객체 중심으로 모니터 안에 접근하는 프로시저를 정의해놓고 제한적으로 접근하도록 함
--> lock을 걸 필요가 없어짐
monitor monitor-name{
// 공유변수 선언
procedure body P1(..){
...
}
procedure body P2(..){
...
}
procedure body P3(..){
...
}
{
initialization code
}
}
Condition variable
Condition x, y;
x.wait()
x가 여분이 있으면 바로 접근 허용, 없으면 줄서서 기다리는 함수를 정의.
x.signal()
빠져나가는 기능
monitor bounded_buffer {
int buffer[N];
condition full, empty ;
void prodduce(int x){
empty.wait(); // 빈 버퍼가 없을 경우
full.signal(); // x가 버퍼에 추가되는 경우
}
void consume(int *x){
full.wait(); // full버퍼가 없을 경우
empty.signal(); // 버퍼에서 데이터를 지우고 저장
}
}