[OS] #10. mutex lock & 스핀락 ( Spinlock ) & CAS ( Compare-And-Swap )

 

 

---

 

 

 

* 동기화 ( Synchronization )

 

동기화 링크 ( 위키 )

 

 

=> 원자성, 가시성, 코드 재배치 문제 등을 해결하기 위한 방법.

 

 

=> 데이터의 일관성을 맞추는 것.

 

순서를 맞추거나 어느 구역을 통제함으로써

데이터를 수정하고 모든 곳에서 같은 값으로 읽을 수 있도록 함.

 

 

=> 멀티 쓰레드 환경에서 동기화를 하지 않는다면 우리가 기대한 결과가 다를 수 있기 때문에

짜여진 프로그램이 정상적으로 동작하기 힘듬.

 

 

=> 대신,

동기화를 위한 알고리즘 등이 필요하고 이를 행하기 위해 비용이 들고 속도가 느려진다.

 

 

 

 

=> 반대의 개념을 '비동기 ( Asynchronous )' 라고 부르는데

순서에 상관 없이 여러 쓰레드가 돌 수 있도록 허가해주는 상태 이다.

 

통제하지 않음으로써 최대의 효율을 낼 수 있지만 데이터의 일관성을 보장할 수 없다.

 

 

 

 

 

 

 

 

 

 

* Lock ( mutex.lock )

 

뮤택스 링크 ( 위키 )

 

 

 

 

 

 

 

=> 해당 구역을 잠가버리는 용도. ( lock )

작업을 마치고 난 후엔 Unlock.

 

 

=> 뮤택스 객체의 Lock 은  '쓰레드 동기화 기법' 이다.

 

 

 

=> 해당 쓰레드가 Lock 한 후 임계 구역에 들어가면

다른 쓰레드들은 접근할 수 없다.

 

 

=> 해당 쓰레드가 해당 구역을 잡고 있는 동안

다른 쓰레드들은 그 구역을 접근하지 못하므로,

락을 빈번하게 사용할 경우 비용이 크다.

 

 

=> Lock-Free 방식도 존재한다. ( Lock 을 사용하지 않는 동기화 방법. )

 

 

 

 

 

 

 

 

 

 

 

 

 

* Busy Waiting ( 바쁜 대기 )

 

바쁜 대기 링크 ( 위키 )

 

 

=> 임계 영역에서 작업 중인 쓰레드가 존재할 때,

아무 작업도 하지 않고 반복적으로 임계 구역에 들어갈 수 있는지

확인하면서 나타나는 현상.

 

 

 

 

 

 

 

 

 

 

 

 

 

* SpinLock ( 스핀락 )

 

바쁜 대기 링크 ( 위키 )

 

 

=> 바쁜 대기를 이용한 방법의 한 종류.

 

 

=> 공유 자원에 대한 권한 획득이 아주 빠른 시간 내에 이루어질 수 있는 확신,

다른 동기화 방법을 이용하기에 비용이 클 때 이용할 수 있다.

 

 

=> 임계 구역에 어떤 쓰레드가 들어가 있어 락이 걸려있는 상황에

while 문을 돌면서 해당 쓰레드가 나올 때까지 기다리고

Unlock 시, 다시 Lock 을 차지하기 위해 경쟁하는 상황.

 

 

 

=> while 문을 계속 도는 이유는 CPU 를 계속 점유하기 위함이다.

이로 인해, 문맥 교환 ( Context Switching ) 이 일어나지 않도록 유도한다.

 

 

 

따라서,

문맥 교환의 비용 없이,

임계 구역에 들어간 프로세스가 나오는 즉시 응답할 수 있다.

 

하지만, 기다리는 시간이 많아진다면 CPU 점유율 이 높아질 수 있다.

 

 

 

 

 

 

 

 

 

 

 

 

* CAS ( Compare-And-Swap ) 알고리즘

 

 

atomic<bool> Locked = false;

bool exptected = false, desired = true;

while (Locked.compare_exchange_strong(expected, desired) == false)
{
	expected = false;
}

 

 

=> atomic 으로 선언된 변수는 '원자성을 보장' 한다.

 

 

=> 해당 변수에 대해 비교하고 바꾸는 과정을 한번에 실행한다.

 

 

=> 이름에서 보이는 것처럼 비교하고 바뀌는 과정은 원자적이고

위에서 말한 Lock 보다 훨씬 가볍고 비용이 적다.

 

 

 

 

위 알고리즘을 통해서

Lock 이 존재하지 않는 'Lock-Free 방식을 구현 가능' 하다.

 

 

하지만,

우리가 구현하기 매우 까다롭다.

왜냐하면, 제일 큰 문제는 검증되지 않았다.

예측하지 못한 예외적인 상황이 존재할 수 있기 때문이고

이를 테스트하기 위해선 많은 시간과 비용이 소모하기 때문에

돈을 주고 사거나 검증되어 구현된 라이브러리를 사용해야겠다.

 

 

 

 

 

---

 

참고 자료

 

 

https://www.youtube.com/watch?v=gTkvX2Awj6g

 

https://cplusplus.com/reference/atomic/atomic/compare_exchange_strong/