C++17 scoped_lock: 여러 뮤텍스를 데드락 없이 잠그기와 lock_guard·unique_lock 비교
이 글의 핵심
뮤텍스를 하나씩 lock_guard로 잠그면 두 스레드가 서로 반대 순서로 잠글 때 데드락이 생기고, 잠금 순서를 규칙으로 정해도 코드가 커지면 지키기 어렵습니다. scoped_lock은 여러 뮤텍스를 데드락 회피 알고리즘으로 한꺼번에 잠그지만, 이동할 수 없고 조건 변수와 함께 쓸 수 없다는 제약이 있습니다. 인접 노드 동시 갱신 예제와 락 종류별 비용 비교까지 정리했습니다.
scoped_lock이란?
std::scoped_lock (C++17)은 여러 뮤텍스를 한 번에 잠그고, 범위를 벗어날 때 자동으로 모두 해제하는 RAII 락입니다. lock_guard의 다중 뮤텍스 버전이며, 데드락 방지를 위해 항상 같은 순서로 잠급니다. 스레드 기초와 데이터 레이스·뮤텍스를 먼저 보면 좋습니다.
#include <mutex>
std::mutex m1, m2;
void func() {
std::scoped_lock lock(m1, m2); // 데드락 방지
// ...
}
왜 필요한가?:
- 데드락 방지: 여러 뮤텍스를 안전하게 잠금
- RAII: 자동 해제로 예외 안전
- 간결성: C++11의 복잡한 코드를 단순화
- 범용성: 단일 및 다중 뮤텍스 모두 지원
// ❌ 수동 잠금: 데드락 위험
std::mutex m1, m2;
void transfer1() {
m1.lock();
m2.lock(); // 데드락 가능!
// ...
m2.unlock();
m1.unlock();
}
void transfer2() {
m2.lock();
m1.lock(); // 데드락 가능!
// ...
m1.unlock();
m2.unlock();
}
// ✅ scoped_lock: 데드락 방지
void transfer1() {
std::scoped_lock lock(m1, m2); // 안전
// ...
}
void transfer2() {
std::scoped_lock lock(m2, m1); // 안전 (순서 무관)
// ...
}
scoped_lock의 동작 원리:
scoped_lock은 내부적으로 std::lock()을 사용하여 데드락 회피 알고리즘으로 모든 뮤텍스를 잠급니다. 소멸자에서 자동으로 모든 뮤텍스를 해제합니다.
// 개념적 구현
// 실행 예제
template<typename... Mutexes>
class scoped_lock {
std::tuple<Mutexes&...> mutexes_;
public:
scoped_lock(Mutexes&... mutexes) : mutexes_(mutexes...) {
std::lock(mutexes...); // 데드락 회피 알고리즘
}
~scoped_lock() {
// 역순으로 해제
unlock_all(mutexes_);
}
// 복사/이동 불가
scoped_lock(const scoped_lock&) = delete;
scoped_lock& operator=(const scoped_lock&) = delete;
};
데드락 회피 알고리즘:
std::lock()은 try-lock 기반 알고리즘을 사용하여 데드락을 방지합니다:
- 첫 번째 뮤텍스를 잠금
- 나머지 뮤텍스를
try_lock()으로 시도 - 실패 시 모두 해제하고 재시도
- 모두 성공할 때까지 반복
// std::lock의 개념적 동작
// 실행 예제
void lock(Mutex& m1, Mutex& m2) {
while (true) {
m1.lock();
if (m2.try_lock()) {
return; // 성공
}
m1.unlock(); // 실패, 재시도
std::this_thread::yield();
}
}
기본 사용
std::mutex mtx;
void func() {
std::scoped_lock lock(mtx);
// 자동 잠금/해제
}
실전 예시
예시 1: 계좌 이체
class Account {
mutable std::mutex mtx; // const 멤버 함수(getBalance)에서도 잠글 수 있도록 mutable
int balance;
public:
Account(int b) : balance(b) {}
friend void transfer(Account& from, Account& to, int amount) {
// 데드락 방지
std::scoped_lock lock(from.mtx, to.mtx);
from.balance -= amount;
to.balance += amount;
}
int getBalance() const {
std::scoped_lock lock(mtx);
return balance;
}
};
transfer의 핵심은 두 계좌의 뮤텍스를 한 번의 scoped_lock으로 잠근다는 점입니다. 스레드 A가 transfer(a, b), 스레드 B가 transfer(b, a)를 동시에 호출해도, 뮤텍스를 하나씩 잠갔다면 A는 a를 잡고 b를, B는 b를 잡고 a를 기다리며 영원히 멈췄을 상황을 std::lock의 알고리즘이 피해 줍니다. getBalance()처럼 const 멤버 함수에서 잠그려면 뮤텍스를 mutable로 선언해야 합니다. 그렇지 않으면 const std::mutex에는 lock()을 호출할 수 없어 GCC 기준 passing 'const std::mutex' as 'this' argument discards qualifiers 같은 컴파일 에러가 납니다.
이 예제에는 한 가지 빠진 경우가 있습니다. 자기 자신에게 이체하는 transfer(a, a, 100)입니다. 이때 scoped_lock은 같은 std::mutex를 두 번 잠그려 하는데, 이미 잠근 스레드가 같은 std::mutex를 다시 잠그는 것은 정의되지 않은 동작이라 대개 그 자리에서 멈춥니다. scoped_lock이 막아 주는 것은 서로 다른 뮤텍스 사이의 순서 문제뿐입니다. 실제 코드에서는 함수 첫 줄에 if (&from == &to) return; 같은 검사를 두어야 하고, 이 경우를 테스트에 넣지 않으면 운영에서 처음 발견되기 쉽습니다.
예시 2: 여러 자원
std::mutex m1, m2, m3;
int data1, data2, data3;
void update() {
std::scoped_lock lock(m1, m2, m3);
data1++;
data2++;
data3++;
}
예시 3: 단일 뮤텍스
std::mutex mtx;
void func() {
std::scoped_lock lock(mtx); // lock_guard와 동일
// ...
}
예시 4: 조건부 잠금
std::mutex m1, m2;
void func(bool needBoth) {
if (needBoth) {
std::scoped_lock lock(m1, m2);
// ...
} else {
std::scoped_lock lock(m1);
// ...
}
}
lock_guard vs scoped_lock
// lock_guard: 단일 뮤텍스
std::lock_guard<std::mutex> lock(mtx);
// scoped_lock: 여러 뮤텍스
std::scoped_lock lock(m1, m2, m3);
// scoped_lock이 더 범용적
자주 발생하는 문제
문제 1: 데드락
// ❌ 수동 잠금 (데드락 가능)
m1.lock();
m2.lock();
// ✅ scoped_lock
std::scoped_lock lock(m1, m2);
문제 2: 순서
// Thread 1
std::scoped_lock lock(m1, m2);
// Thread 2
std::scoped_lock lock(m2, m1); // OK: 데드락 방지
문제 3: 예외 안전성
std::scoped_lock lock(m1, m2);
process(); // 예외 발생해도 자동 unlock
문제 3-1: 이름 없는 임시 객체와 빈 scoped_lock
std::mutex mtx;
void bad1() {
std::scoped_lock{mtx}; // ❌ 임시 객체: 이 줄이 끝나면 바로 해제됨
shared_data++; // 잠금 없이 실행
}
void bad2() {
std::scoped_lock lock; // ❌ 뮤텍스를 하나도 잠그지 않는 scoped_lock<>
shared_data++;
}
두 코드 모두 경고 없이 컴파일된다는 점이 위험합니다. bad1은 변수 이름을 빠뜨려 임시 객체가 만들어졌다가 세미콜론에서 바로 소멸하므로, 잠금은 한순간만 유지됩니다. bad2는 뮤텍스 인자를 빠뜨린 경우인데, scoped_lock이 0개 이상의 뮤텍스를 받는 가변 인자 템플릿이라 인자 없는 scoped_lock<>도 합법적인 타입이 되어 아무것도 잠그지 않습니다. lock_guard는 인자가 없으면 컴파일 에러가 나지만 scoped_lock은 그렇지 않아서, 단일 뮤텍스에 lock_guard 대신 scoped_lock을 쓰는 스타일을 택했다면 이 실수를 리뷰에서 특히 주의해야 합니다. clang-tidy의 bugprone-unused-raii 검사가 첫 번째 경우를 잡아 줍니다.
문제 4: 이동 불가
std::scoped_lock lock(mtx);
// ❌ 이동 불가
// auto lock2 = std::move(lock);
// unique_lock 사용 필요
std::unique_lock<std::mutex> ulock(mtx);
auto ulock2 = std::move(ulock); // OK
C++11 대안
// C++11: std::lock + lock_guard
std::mutex m1, m2;
void func() {
std::lock(m1, m2);
std::lock_guard<std::mutex> lock1(m1, std::adopt_lock);
std::lock_guard<std::mutex> lock2(m2, std::adopt_lock);
}
// C++17: scoped_lock (간단)
void func() {
std::scoped_lock lock(m1, m2);
}
실무 패턴
패턴 1: 안전한 스왑
template<typename T>
class ThreadSafeContainer {
mutable std::mutex mtx_;
T data_;
public:
void swap(ThreadSafeContainer& other) {
if (this == &other) return;
// 데드락 방지
std::scoped_lock lock(mtx_, other.mtx_);
std::swap(data_, other.data_);
}
T get() const {
std::scoped_lock lock(mtx_);
return data_;
}
};
패턴 2: 다중 자원 업데이트
class ResourceManager {
std::mutex cpuMtx_, memMtx_, diskMtx_;
int cpuUsage_, memUsage_, diskUsage_;
public:
void updateAll(int cpu, int mem, int disk) {
std::scoped_lock lock(cpuMtx_, memMtx_, diskMtx_);
cpuUsage_ = cpu;
memUsage_ = mem;
diskUsage_ = disk;
}
void updateCpu(int cpu) {
std::scoped_lock lock(cpuMtx_);
cpuUsage_ = cpu;
}
};
패턴 3: 계층적 잠금
class BankSystem {
std::mutex accountsMtx_;
std::mutex transactionsMtx_;
std::mutex auditMtx_;
public:
void transfer(int from, int to, double amount) {
// 계좌와 트랜잭션 잠금
std::scoped_lock lock(accountsMtx_, transactionsMtx_);
// 계좌 이체
}
void audit() {
// 모든 자원 잠금
std::scoped_lock lock(accountsMtx_, transactionsMtx_, auditMtx_);
// 감사 수행
}
};
lock_guard vs scoped_lock vs unique_lock (한눈에 비교)
세 클래스 모두 RAII로 뮤텍스를 잠그지만, 역할과 비용이 다릅니다.
| 구분 | lock_guard | scoped_lock | unique_lock |
|---|---|---|---|
| C++ 버전 | C++11 | C++17 | C++11 |
| 뮤텍스 개수 | 1개 | 1개 이상 (가변 인자) | 1개 |
std::lock 다중 잠금 | 직접 조합 필요 | 내장 (std::lock 호출) | std::unique_lock + std::lock 패턴 |
수동 unlock / defer_lock | 불가 | 불가 | 가능 (defer_lock, try_to_lock 등) |
condition_variable | mutex만으로는 제한적 | 보통 CV와 함께 쓰기엔 unique_lock | 표준 조합 |
| 이동 | 불가 | 불가 | 가능 |
선택 가이드
- 단일 뮤텍스, 잠금 범위가 블록 전체 →
lock_guard또는scoped_lock한 개 인자. 스타일 통일을 위해 팀이scoped_lock만 쓰기도 합니다. - 두 개 이상 뮤텍스를 항상 같이 잠가야 함 →
scoped_lock이 가장 단순하고 데드락 회피 알고리즘이 한 번에 들어갑니다. - 중간에 잠금 해제, 재잠금, 조건 변수 대기, 타임아웃 시도 →
unique_lock이 필수입니다.
std::mutex m;
std::condition_variable cv;
bool ready = false;
void wait_ready() {
std::unique_lock<std::mutex> lk(m); // scoped_lock으로 대체 불가
cv.wait(lk, [] { return ready; });
}
데드락 방지: 잠금 순서만으로 부족할 때
scoped_lock은 같은 호출에서 잡는 여러 뮤텍스에 대해 std::lock 기반으로 순서를 정리해 줍니다. 하지만 다음은 여전히 위험합니다.
- 한 스레드은
scoped_lock(m1,m2), 다른 스레드는m1만 잡고 블로킹된 채m2를 기다리는 식으로 설계가 어긋난 경우. - 락 없이 공유 자료를 읽고, 다른 곳에서는 락을 잡고 쓰는 혼합 사용.
- 콜백·가상 함수 안에서 모르는 사이 다른 락을 잡는 비재진입(non-reentrant) 뮤텍스 중첩.
실무에서는 “전역 순서 번호”를 자원에 매기고, 항상 번호가 작은 뮤텍스부터 잠그는 규칙과 scoped_lock을 같이 쓰면 이해와 검증이 쉬워집니다. 이미 scoped_lock이 순서를 자동으로 맞춰 주더라도, 코드 리뷰 시 잠금 경로를 한눈에 보이게 하는 데 도움이 됩니다.
여러 뮤텍스를 동시에 잠글 때의 실무 체크
- 같은 두 객체를 서로 다른 순서로 잠그는 코드가 있다면
scoped_lock(a,b)와scoped_lock(b,a)모두 안전하지만, 일부만 잠그는 경로가 섞이지 않았는지 확인하세요. - std::shared_mutex와 일반
mutex를 함께 쓸 때는 읽기/쓰기 규칙을 문서화하세요.scoped_lock은 타입이 달라도 여러 개를 한 번에 잠글 수 있습니다(각각이 BasicLockable이면 됨). - 락 보유 시간을 최소화하세요.
scoped_lock으로 넓은 범위를 잡아 두고 I/O나 네트워크 호출을 하면 전체 처리량이 떨어집니다.
실전 예제 보강: 인접 노드 두 개를 동시에 갱신
그래프에서 엣지 (u, v)를 갱신할 때 두 정점의 내부 뮤텍스를 모두 잠가야 한다면, 정점 id 순으로만 잠그도록 하거나 scoped_lock(mtx[u], mtx[v])를 사용합니다.
struct Vertex {
std::mutex mtx;
int value{};
};
std::vector<Vertex> graph;
void add_edge_value(size_t u, size_t v, int delta) {
if (u == v) return;
// 정점별 뮤텍스 — 순서가 매번 바뀌어도 데드락 회피
std::scoped_lock lk(graph[u].mtx, graph[v].mtx);
graph[u].value += delta;
graph[v].value += delta;
}
성능 비교: 무엇이 비싼가
- 단일
mutex, 경쟁이 심하지 않을 때:lock_guard와scoped_lock(mtx)는 동일한 수준의 비용(뮤텍스 잠금 자체가 지배적)입니다. - 다중 뮤텍스:
std::lock은 필요 시 try_lock·언락·재시도를 하므로, 최선 경로(한 번에 모두 잠김)보다 약간 더 나쁠 수 있습니다. 그 대신 데드락 없음이라는 비용으로 보는 것이 맞습니다. - 벤치마크 시 주의: 나노초 단위로만 비교하기보다, 실제 임계 구역 길이·경쟁 스레드 수에서 전체 응답 시간을 재는 편이 의미 있습니다.
요약하면, 단일 락이면 세 타입 중 “가장 단순한 것”, 다중 락이면 scoped_lock, 조건 변수·유연한 잠금이면 unique_lock이 기본 선택입니다.
FAQ
Q1: scoped_lock은 무엇인가요?
A: C++17에서 도입된 여러 뮤텍스를 동시에 잠그는 RAII 락입니다. 데드락을 방지하고 자동으로 해제합니다.
std::mutex m1, m2;
void func() {
std::scoped_lock lock(m1, m2); // 데드락 방지
// 자동 해제
}
Q2: 데드락을 어떻게 방지하나요?
A: 내부적으로 std::lock()의 데드락 회피 알고리즘을 사용합니다. 여러 뮤텍스를 안전하게 잠급니다.
// Thread 1
std::scoped_lock lock(m1, m2);
// Thread 2
std::scoped_lock lock(m2, m1); // OK: 데드락 방지
동작 원리: 하나를 잠근 뒤 나머지를 try_lock()으로 시도하고, 실패하면 이미 잡은 것을 모두 풀고 다른 순서로 다시 시도합니다. “원자적으로 잠근다”기보다 잠금을 보유한 채 다른 잠금을 기다리지 않는다는 것이 데드락이 생기지 않는 이유입니다. 경쟁이 심하면 풀고 다시 잡는 과정이 반복될 수 있지만, 표준은 결국 모두 잠그는 것만 보장하고 구체적인 알고리즘은 구현에 맡깁니다.
Q3: lock_guard와 어떤 차이가 있나요?
A:
- lock_guard: 단일 뮤텍스만 지원
- scoped_lock: 단일 및 다중 뮤텍스 모두 지원
// lock_guard: 단일만
std::lock_guard<std::mutex> lock(mtx);
// scoped_lock: 단일 및 다중
std::scoped_lock lock1(mtx); // 단일
std::scoped_lock lock2(m1, m2, m3); // 다중
권장: C++17 이상에서는 scoped_lock 사용
Q4: 이동할 수 있나요?
A: 불가능합니다. scoped_lock은 복사와 이동이 모두 금지됩니다. 이동이 필요하면 unique_lock을 사용하세요.
std::scoped_lock lock(mtx);
// auto lock2 = std::move(lock); // 에러
// unique_lock 사용
std::unique_lock<std::mutex> ulock(mtx);
auto ulock2 = std::move(ulock); // OK
Q5: 성능은 어떤가요?
A: 단일 뮤텍스의 경우 lock_guard와 동일합니다. 다중 뮤텍스의 경우 데드락 회피 알고리즘으로 인한 약간의 오버헤드가 있지만, 안전성을 고려하면 무시할 수 있습니다.
// 단일: lock_guard와 동일한 성능
std::scoped_lock lock(mtx);
// 다중: 약간의 오버헤드 (데드락 회피)
std::scoped_lock lock(m1, m2, m3);
Q6: C++11/14에서는 어떻게 하나요?
A: std::lock()과 lock_guard를 조합하여 사용합니다.
// C++11/14
std::mutex m1, m2;
void func() {
std::lock(m1, m2); // 데드락 회피
std::lock_guard<std::mutex> lock1(m1, std::adopt_lock);
std::lock_guard<std::mutex> lock2(m2, std::adopt_lock);
}
// C++17: 훨씬 간단
void func() {
std::scoped_lock lock(m1, m2);
}
Q7: 조건부로 여러 뮤텍스를 잠글 수 있나요?
A: 가능하지만, 각 경우마다 별도의 scoped_lock을 사용해야 합니다.
void func(bool needBoth) {
if (needBoth) {
std::scoped_lock lock(m1, m2);
// 둘 다 잠금
} else {
std::scoped_lock lock(m1);
// m1만 잠금
}
}
Q8: 같은 뮤텍스를 두 번 넘기면 어떻게 되나요?
A: std::scoped_lock lock(m, m);이나 transfer(a, a)처럼 같은 std::mutex가 두 번 들어가면 한 스레드가 이미 잡은 뮤텍스를 다시 잠그게 되어 정의되지 않은 동작입니다(대개 멈춥니다). std::recursive_mutex라면 재진입이 허용되지만, 설계로 막는 편이 낫습니다. 동일 객체인지 먼저 비교하고 한 번만 잠그세요. 세부 규칙은 cppreference의 std::scoped_lock 문서에 있습니다.
관련 글: 뮤텍스·lock_guard, shared_mutex, 데이터 레이스·뮤텍스, 스레드 기초.
std::scoped_lock은 여러 뮤텍스를 데드락 없이 안전하게 잠그는 C++17 RAII 락입니다.
같이 보면 좋은 글
- C++ mutex와 lock_guard·unique_lock·scoped_lock: 임계 영역 보호와 데드락 방지
- C++17 shared_mutex: 읽기-쓰기 락으로 동시 읽기 허용하기와 쓰기 기아
- Data Race 잡는 법: Mutex와 Atomic 중 뭘 써야 할까
- C++ std::thread 입문 | join 누락·디태치 남용 등 자주 하는 실수 3가지와 해결법
- C++ CTAD