Mutex Locks

Mutex Locks

---

hardware적이기만 한 solution을 통한 동기화 문제 해결은 빠르지만 application, programmer 입장에서 사용하기 어렵고, busy waiting과 같은 문제가 나타날 수 있는 단점이 존재했다.

그렇기에 software적인 부분과 hardware적인 부분이 섞인 다른 software tool이 필요하게 되었는데, 그 중 하나가 Mutex Lock이다.

 

mutex는 이진 semaphore의 일종으로 resource에 lock을 걸면서 동기화 문제를 해결한다.

상호 배제(mutual exclusion: 한 번에 한 process만 critical section에 들어갈 수 있도록 하는 것) 개념을 이용하여 critical section을 가진 thread들이 각각 단독으로 실행되게 하는 기술이다. 그래서 이름도 mut(ual) ex(clusion)의 축약 형태이다.

 

좀 더 쉽게 설명하자면, critical section에 들어가기 위해서는 하나의 key가 필요하고 어떤 thread가 key를 얻어 critical section에 진입했다면, 다른 thread는 key를 얻을 때까지 기다려야 한다는 것이다.

 

다음 aquire() 함수는 lock을 획득하고 release() 함수가 lock을 반환한다.

acquire

acquire() {
	
    while(!available);
    available = false;
}

release

release() {
	
    available = true;
}

 

Spinlock: mutex lock 유형 중 하나

---

Mutex lock을 사용한 critical section 문제 해결

while(true) {
	
    aquire lock
    	critical section
    release lock
    	remainder section
}

acquire() 또는 release() 함수 호출은 atomic하게 수행되어야 한다.

 

그런데 아직까지는 위처럼 구현한다면 busy waiting을 해야 한다는 단점이 존재한다. 어떤 process가 critical section에 있는 동안 critical section에 들어가기를 원하는 다른 process들은 acquire() 함수를 호출하는 반복문을 계속 실행해야 한다. 이것을 lock을 사용할 수 았을 때까지 process가 회전한다고 한다.

 

실제로 위의 구현 방식을 그대로 사용하면 multi thread를 사용할 때 여러 thread가 동시에 while(true)를 반복하는 경험을 할 수 있다...

 

그래서 Non busy wait: 다른 thread가 mutex lock을 사용하고 있다면 이 thread가 lock을 해제하기 전까지 해당 지점에 머물러 있으며 이 동안 어떠한 CPU 자원도 소비하지 않도록 해야 한다. 이를 위해 일시적으로 대기 process를 휴면 상태로 전환한 후 lock을 사용할 수 있게 되면 깨우는 전략을 사용한다.

 

그러나 spinlock의 경우에도 장점이 있는데

non busy wait를 위해서 context switch가 필요하므로(휴먼 상태로/에서의 전환이 필요할 때) 이 부분에서의 overhead가 존재할 수 밖에 없는데 spinlock의 경우에는 이러한 context switch가 없으므로 만일 critical section이 굉장히 짧다면, 기다리는 회전하는 process의 수가 굉장히 적고 또 그만큼 빨리 끝날 것이므로 오히려 block의 방식보다 더 빠를 수 있다.

 

(critical section이 굉장히 짧은 경우에는 오히려 context switch의 overhead가 더 커질 수 있다는 것!)