Race condition(경쟁상태)
-여래개의 프로세스가 동시에 공유 자원에 접근할 때 순서가 달라지므로 결과 값도 달라진다.
- 불확실한 상태
- 여러 프로세스들이 동시에 접근한다 -> 순서 보장 x
-프로세스 P0 및 P1 은 다음을 사용하여 자식 프로세스를 생성한다.
fork() system call
- 다음 available process identifier(pid)를 나타내는 경쟁 상태 안의 커널 변수 next_available_pid
P0 및 P1이 next_available_pid 변수에 액세스 하는 것을 방지하는 메커니즘이 없으면 동일한 pid가 2개의 다른 프로세스에 할당될 수 있다. (비정상적 상태)
-동기화로 해결해야 한다.
Critical Section Problem
- 시스템에 n개의 프로세스들이 있다고 하자. {P0,P1, P2,... Pn-1}
-각각의 프로세스들은 코드에 분할된 critical section이 있다.
• 프로세스는 공통 변수 변경, 테이블 업데이트, 파일 쓰기 등을 할 수 있다.
• 하나의 프로세스가 critical section에 접근하면 , 다른 프로세스는 그 섹션에 접근할 수 없다.
- Critical section problem은 이문제를 해결하기 위해 만들어진 프로토콜이다.
- 각각의 프로세스들은 entry section안의 critical section에 들어가기 이 헤 권한을 요청해야 하며, exit section이 있는 critical section을 따르고 다음에는 remainder section일 것이다.
-Race condition이 일어나지 않기 위해 이 section에 있는 code는 무조건 아무런 반응 없이 한 번에 수행되어야 한다.
스케쥴러가 원하는 대로 스케쥴링을 해주지는 않지만, 프로그램에서 이 자원만큼은 접근을 막는 즉, 하나의 프로세스가 이 자원을 관리할 때 다른 프로세스들이 접근을 못 하도록 해주는 것을 말한다.
*entry section: critical section에 들어가게 해 준다. 요청을 관리함.
*exit section: critical section에서 나간다.
*remainder section: critical이 아닌 다른 section을 처리한다.
-concurrent 환경에서는 예측이 불가능하여 따로 보호가 필요하다. 공유 자원, 외부 장치, 네트워크 통신에서는 특히 critical section이 필요하다.
-이 문제를 해결하려면 3가지가 반드시 필요로 한다.
1. Mutual Exclusion(상호베타): 만약 프로세스 Pi가 크리티컬 섹션에서 실행되면, 다른 프로세스들은 그들의 크리티컬 섹션에 진입할 수 없다.
2. Progress(진행): 크리티컬 섹션에서 실행되는 프로세스가 없고, 다른 프로세스들이 크리티컬 섹션에 들어가기를 원한다면, 이들의 순서가 유한 시간 내에 정해져야 한다.
3. 유한 대기(Bounded waiting): 프로세스가 중요 섹션에 진입하기 위한 요청을 수행한 후 및 해당 요청이 승인되기 전에 다른 프로세스가 중요 섹션에 진입하도록 허용되는 횟수, 범위에 제한이 존재한다. 즉 시간이 정해져 있다.
• 우리는 각 프로세스가 0의 속도가 아닌 속도로 실행된다고 믿는다. 하지만 우리는 n개의 프로세스의 상대적인 속도에 관한 가정을 할 수 없다.
Mutex Locks
- mutex lock: OS 디자이너들이 crirical section problem을 해결하기 위해 더 높은 소프트웨어 도구를 만들었고 가장 간단한 도구이다. (부울 변수를 사용하여 잠금이 가능한지 아닌지 확인 가능하다.)
- 크리티컬 섹션을 보호해서 결과적으로 경쟁상태가 예방된다.
- 크리티컬 섹션 보호하는 법-프로세스는 반드시 크리티컬 섹션을 들어가기 전에 락을 얻어야 한다; 그것이 크리티컬 섹션을 나갈 때 락을 제공하기 때문이다.
- 먼저 aquire() 함수로 락을 얻는다.
- 그다음 release() 함수로 락을 해제한다.
-잠금이 이용 가능한 경우, aquire()을 위한 호출이 성공하고, 그다음에 잠금이 이용 불가능한 것으로 간주된다. 이용 불가능한 잠금을 획득하려고 시도하는 프로세스는 잠금이 해제될 때까지 차단된다.
- acquire() 콜과 release() 콜은 반드시 원자적이어야 한다.(방해받지 않고 더 이상 나뉘지 않는다.)
- 하지만 이것은 busy waiting이 필요로 한다. 그래서 이 락은 spinlock이라도 불린다.
* busy waiting: lock을 얻을 수 없으면 계속 lock을 확인하며 얻을 때까지 기다린다.
* spinlock: 무한루프를 돌면서 lock을 기다리며 CPU 시간을 많이 소모한다. = mutex lock
