<Semaphore 세마포어> - mutex lock 확장판. 보편적.
동기화: 순서를 지정할 때도 사용. mutex는 race만.
• Semaphore S: integer 값 – wait, signal로만 접근
• 원자적으로만 사용 가능
• wait()는 들어가기 위해 기다리는. ⇨ P()
-자원이 1개 이상 있는지 확인, 점유, S 감소 (원자적)
• signal()은 기다리는 애에게 신호보내는. ⇨ V()
<세마포어 다양한 동기화 문제>
① Binary 세마포어: 0 또는 1 값만 가짐
• S1 = 1 (초기값을 1로 두면 mutex lcok과 똑같음)
② Counting 세마포어: 유한한 개수의 자원 사용 통제
• S1 > 1 (이 경우 Critical section은 XX)
▷ Race 상황(S1=1인 ①)
▷ 순서를 동기화 하는 상황
• Binary 세마포어 S1 = 0 (초기값이 0)
• T2가 wait을 먼저 호출했으므로 초기값이 0이라서
wait안에 갇혀 있음(S1=1이 될 때까지)
• T1이 끝나고
signal이 오면 T2 실행.
<세마포어의 문제> - 타이밍 에러(timing errors)가 발생
• 세마포어 연산의 잘못된 사용⇨임계 구역이 보호 받지x
- signal(mutex)...wait(mutex) ⇨상호배제x
- wait(mutex)...wait(mutex) ⇨무한대기
- wait(mutex) 또는 signal(mutex) 생략 ⇨보호x
- P(s1)...V(S2) ⇨잘못 사용된 것을 알아채기 힘듦
• Deadlock 교착 / starvation 기아 상태 발생 가능
<Monitor 모니터> - OS의 기능은x / 언어에서 제공
등장 배경: 구조체만 사용하면 사용하기 쉽지 않을까?
• 세마포어는 구조화되지 않은 구조
-동기화 버그에 취약(race 상태)
-너무 low레벨
• 프로세스 동기화를 위한 높은 수준의 추상화가 필요
-Lock이 숨겨져 있음 / 자동으로 잠금 및 해제
-데이터 및 프로시저를 포함하는 병행성 구조
⇨사용자가 수행하기 휠씬 쉬움
<모니터 역할>
공유 자원을 내부적으로 숨기고 공유 자원에 접근하기 위한 인터페이스만 제공
- 자원 보호, 프로세스 간 동기화
<모니터 특징>
• 추상 데이터 타입(ADT) / 프로시저 코드 내부 변수
• 한 번에 하나의 프로세스만 모니터 내에서 활성화
<고전 동기화 문제>
• Readers and Writers Problem
• Dining-Philosophers Problem
<Readers and Writers Problem 읽기 쓰기 문제>
-데이터 set을 여러 프로세스가 공유 중일 때
• Readers – 읽기만 가능 프로세스
• Writers – 읽기+쓰기 가능 프로세스
-읽기 프로세스는 여러 명이 병행 수행 가능하다.
-Writer 1명이 사용 중이면 접근은 이 1명만 가능하다.
<Dining-Philosophers Problem 철학자 만찬 문제>
- 다섯 명의 철학자 / 다섯 개의 젓가락
- 생각, 배고픔, 먹기 3단계를 반복
- 공유 자원에는 누구나 접근 가능한데, 조건이 젓가락
- 다섯 개의 세마포어를 1로 초기화
• semaphore chopstick[5];
• 문제점: 상호배제는 만족하지만 Deadlock 발생
