[CS] 동기화 메커니즘이 왜 필요할까?

devlcw·2024년 5월 4일

동기화 메커니즘이 필요한 이유

우리가 이전 포스트에서 동기화 메커니즘에 어떤 종류가 있는지 알아봤다. 이번 포스트에서는 실질적으로 동기화 메커니즘이 왜 필요한 지에 대해서 알아보겠다.

동기화 메커니즘은 자원 동기화가 목적이다. 그런데, 이 자원 동기화 없이 비동기 프로그래밍을 한다면 어떤 상황이 발생할까? 한번 살펴보자.
우선 현실 문제로 예시를 들어보겠다.

현실적인 문제 예시

1. 은행 계좌 출금

Bob과 Alice가 동일한 은행 계좌에서 동시에 금액을 출금하려고 한다. Bob은 ATM에서, Alice는 온라인 뱅킹을 통해 거래를 한다. 동기화 메커니즘이 없다면, 두 거래가 거의 동시에 이루어져 계좌의 잔액을 정확히 감소시키지 못할 수 있다. 이유는 잔액이 과다하게 표시되어 두 사람 모두 출금을 시도할 수 있게 되고, 결과적으로 계좌는 마이너스 잔액을 보게 된다.

2. 공유 데이터의 동시 수정

Bob과 Alice가 공동 작업을 하는 문서를 동시에 편집한다고 가정하자. Bob은 문서의 첫 번째 부분을 수정하고, Alice는 거의 동시에 마지막 부분을 수정한다. 여기서 동기화 없이는 Bob의 변경사항이 Alice의 변경사항에 의해 덮어질 수 있다.

위 예시들이 모두 동기화 메커니즘을 적용하지 않아서 나오는 문제들이다. 흔히 데이터 레이스, 레이스 컨디션이라고 불린다.

데이터 레이스 (Data Race)

위 예시들이 모두 이 데이터 레이스다. 데이터 레이스란 변경 가능한 메모리에 접근하는 동안 쓰기 작업을 하는 것이다.
즉, 순서가 알 수 없기에 실행 결과를 알 수 없어져 예상할 수 없는 결과가 나온다는 아주 위험한 오류다. 위 예시들만 봐도 그렇다.

레이스 컨디션 (Race Condition)

레이스 컨디션은 또 다른 개념인데, 데이터 레이스의 상위 개념이라고 착각할 수 있지만, 아니다. 공통점은 존재하되 서로 다른 개념이라고 볼 수 있다.
레이스 컨디션이란 타이밍이나 순서가 코드 조각의 정확성에 영향을 미칠 때 발생하는 여러 오류들을 일컫는 말이다.

데이터 레이스는 읽기/쓰기가 명확하게 나와있지만 이건 포괄적인 개념이다. 이런 점에서 데이터 레이스와 차이가 있다. 단순히 읽기만 하는데 순서를 알 수 없다면? 이건 데이터 레이스가 아닌 것이다.

하지만 동기화 메커니즘을 적용한다고 해도 관리를 잘못하면 생길 수 있는 문제들이 있다.
바로 데드락이란 개념이다.

데드락 (Deadlock)

데드락은 두개 이상의 락(Lock)이 서로의 작업이 끝나기를 기다리며 작업 진행이 안되는 상태에 빠지는 것을 말한다.

데드락은 다음과 같은 상황을 모두 만족시켜야 일어날 수 있다.

필요 조건

Mutual Exclusion (상호 배제) - 하나의 자원에 대해 한 쓰레드만 가질 수 있는 상황
Hold and Wait (점유 대기) : 프로세스가 자원을 할당한 채로 다른 자원을 기다리는 상황
No Preemption (비선점) : 프로세스가 어떤 자원의 사용이 끝나기 전 까진, 그 자원을 반환할 수 없는 상황
Circular Wait (순환 대기) : 각 프로세스는 순환적으로 다음 프로세스가 요구하는 자원을 가지고 있는 상황

모두 전 포스팅을 읽고 왔다면 굉장히 이해하기 쉬울 것이다.
Mutex나 Semaphore, SpinLock 등등 동기화 메커니즘들을 잘못 사용할 때 데드락이 발생할 수 있다.

예시 상황

Bob과 Alice가 컴퓨터를 사용하려고 한다.
Bob은 키보드를 점유하고 있고 Alice는 컴퓨터를 점유하고 있다.
Alice는 키보드가 있어야 현재 에디터로 진행중인 코드를 저장하고 컴퓨터를 끌 수 있다.
Bob은 컴퓨터가 있어야 에디터로 코딩을 할 수 있다.

이런 상황이 발생되면 더 이상 작업이 진행되지 않게 된다.

해결 방법

1. 예방

이런 상황을 예방하는 방법은 위 필요 조건을 깨면 된다. 예를 들어 러스트에서는 Mutex 말고 RwLock이라는 읽을 때 상호 배제가 없어도 되는 락이 존재한다. 이런식으로 예방할 수도 있고,

2. 회피

데드락을 회피할 수 있는 방법도 있다. 은행원 알고리즘이라고 불리는 이 회피 방법은 각 프로세스가 최대로 요구할 수 있는 자원 양을 사전에 알고, 이를 기반으로 안전한 자원 할당 결정을 합니다. 현재의 자원 요청이 시스템을 불안전한 상태로 만들지 않을 때만 자원을 할당한다.
이게 무슨 말인지 잘 이해가 안 될수도 있는데 최대한 쉽게 흐름을 설명해보겠다.

초기 설정
각 프로세스의 최대 자원 요구량(Max)을 설정한다.
시스템에서 사용 가능한 총 자원(Available)을 설정한다.
각 프로세스에 현재 할당된 자원(Allocation)을 기록한다.
각 프로세스의 추가로 필요한 자원(Need)을 계산한다. (Need = Max−Allocation
자원 요청
프로세스가 자원을 요청할 때, 요청량(Request)을 받는다.
요청 검증
요청된 자원이 해당 프로세스의 필요량(Need)을 초과하지 않는지 확인한다
요청된 자원이 사용 가능한 자원(Available)을 초과하지 않는지 확인한다.
안전성 검사
요청을 승인했을 때 시스템이 안전 상태로 유지될 수 있는지 시뮬레이션을 통해 확인한다.
요청이 수락된 후, 모든 프로세스가 필요한 자원을 받고 성공적으로 완료될 수 있는 순서(Safe Sequence)가 존재하는지 검사한다.
자원 할당
안전 상태가 확인되면, 요청된 자원을 프로세스에 할당한다.
Available과 Allocation을 업데이트하고, 필요한 자원(Need)을 감소시킨다.
프로세스 완료
프로세스가 작업을 완료하고 자원을 반환하면, 시스템의 Available 자원을 업데이트한다.