공유된 자원을 여러 프로세스(스레드)가 동시에 접근할때, 접근하는 순서에 따라서 결과가 달라질 수 있는 상태를 의미한다.
코드 내에서 위의 Race Condition이 발생할 수 있는 영역을 Critical Section 이라고 한다.
이 문제(Critical Section)를 해결하기 위해서는 다음 조건 모두를 만족해야한다.
어떤 한 프로세스가 공유된 자원을 접근해 사용중일 경우, 다른 프로세스는 이 자원에 접근해서는 안된다.
Critical Section에 접근해있는 프로세스가 없는 경우(Mutual Exclusion에 해당하지 않는 경우)에 해당 섹션에 접근하려는 프로세스가 생기면 그 프로세스는 자원에 접근할 수 있어야 한다. (선택이 연기될 수 없으며, 진입 요청한 프로세스들로만 순서가 결정되어야 한다)
한 프로세스가 Critical Section에 접근하고자 요청을 한 후 그 요청이 수락될 떄까지 다른 프로세스가 이 임계구역에 접근할 수 있는 횟수가 제한되어야함.
ex) 프로세스 A가 C자원을 사용중이다가, B가 요청을 하고 대기하고 있는데 또 A가 C자원을 요청해서 계속 자원을 붙잡으려고 하는 경우 B는 영원히 자원에 접근할 수 없는 상태가 될 수 있음
Lock, Unlock을 Atomic한 객체로 두어서 자원을 점유하고있는지에 대한 상태를 가지고 있고, 점유하고있는 경우 접근을 제한한다.
그림과 마찬가지로 락이 걸려있는 상태이면 while에 의해서 무한 대기하고, 그게 아닌 경우 락을 잠그게끔 되어있다.
하지만 그림과 같은 무한대기는 CPU의 자원을 낭비하고 그로 인한 지속적인 Context Switching이 발생하기에 유용하지는 않은 방법이다.
Counter형태의 변수 S로 동시에 접근 가능한 프로세스를 제안하는 방식으로, Mutex방식과의 차이는 여러 프로세스가 동시에 대기하고 그 수를 관리할 수 있다는 점이다.
물론 Mutex와 같이 이 무한대기 방법은 CPU의 자원을 낭비하기에,
다음과 같이 스레드/프로세스 자체를 블로킹시켜서 대기하게끔 하고 그 후 접근 가능한 시점에서 깨워주는 방식으로 주로 사용된다.
Mutex와 다르게, 동기화를 위해 wait와 signal이라는 2개의 Atomic 동작을 이용하여, 락을 걸지 않은 쓰레드도 signal을 보내 락을 해제할 수 있다는 차이점이 있다.
https://github.com/JaeYeopHan/Interview_Question_for_Beginner/tree/master/OS#%ED%94%84%EB%A1%9C%EC%84%B8%EC%8A%A4-%EB%8F%99%EA%B8%B0%ED%99%94
https://mangkyu.tistory.com/104