C++17 scoped_lock: 여러 뮤텍스를 데드락 없이 잠그기와 lock_guard·unique_lock 비교
이 글의 핵심
뮤텍스를 하나씩 lock_guard로 잠그면 두 스레드가 서로 반대 순서로 잠글 때 데드락이 생기고, 잠금 순서를 규칙으로 정해도 코드가 커지면 지키기 어렵습니다. scoped_lock은 여러 뮤텍스를 데드락 회피 알고리즘으로 한꺼번에 잠그지만, 이동할 수 없고 조건 변수와 함께 쓸 수 없다는 제약이 있습니다. 인접 노드 동시 갱신 예제와 락 종류별 비용 비교까지 정리했습니다.
scoped_lock이란?
std::scoped_lock (C++17)은 여러 뮤텍스를 한 번에 잠그고, 범위를 벗어날 때 자동으로 모두 해제하는 RAII 락입니다. C++ mutex: 경쟁 상태, 데드락, lock_guard·scoped_lock 사용 원칙에서 다룬 lock_guard의 다중 뮤텍스 버전입니다. 인자로 받은 뮤텍스들을 고정된 순서로 잠그는 것이 아니라, std::lock의 데드락 회피 알고리즘으로 잠그기 때문에 호출마다 인자 순서가 달라도 서로 교착하지 않습니다. 스레드와 뮤텍스가 처음이라면 스레드 기초를 먼저 보면 좋습니다.
#include <mutex>
std::mutex m1, m2;
void func() {
std::scoped_lock lock(m1, m2); // 데드락 방지
// ...
}뮤텍스를 하나씩 직접 잠그면, 두 함수가 같은 뮤텍스들을 서로 다른 순서로 잠글 때 각자 하나씩 쥔 채 상대가 쥔 것을 영원히 기다리게 됩니다. 아래 transfer1과 transfer2가 동시에 실행되면 그런 상황이 됩니다. scoped_lock은 여러 뮤텍스를 한 번에 잠그면서 이 교착을 피하고, 소멸자에서 모두 풀어 주므로 예외가 나도 잠금이 남지 않습니다.
// 수동 잠금: 데드락 위험
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은 내부적으로 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 기반입니다. 하나를 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);
// 자동 잠금/해제
}std::scoped_lock은 C++17의 클래스 템플릿 인자 추론(CTAD) 덕분에 std::scoped_lock<std::mutex>라고 쓰지 않고 std::scoped_lock lock(mtx);처럼 적을 수 있습니다. 소멸자가 뮤텍스를 해제하므로 return이나 예외로 함수를 빠져나가도 잠금이 남지 않습니다. 직접 확인한 내용은 다음과 같습니다(macOS arm64, Apple clang 21.0.0, -std=c++20).
std::scoped_lock lk(m1, m2);안에서m1.try_lock()을 호출하면 0(실패)이고, 블록을 벗어난 뒤에는 1(성공)이었습니다.- 크기는
sizeof(std::scoped_lock<std::mutex>)가 8바이트,sizeof(std::scoped_lock<std::mutex, std::mutex>)가 16바이트,sizeof(std::lock_guard<std::mutex>)가 8바이트였습니다. 뮤텍스 참조를 하나씩 들고 있는 크기입니다. - 뮤텍스를 하나도 넘기지 않은
std::scoped_lock none;도 컴파일됩니다. 가변 인자 템플릿이라 개수가 0이어도 문법상 허용됩니다.
변수 이름을 빼먹는 실수도 주의해야 합니다. std::scoped_lock(m1);처럼 이름 없이 쓰면 임시 객체를 만드는 것이 아니라 m1이라는 이름의 변수를 선언하는 문장으로 해석됩니다. 이렇게 만들어진 것은 뮤텍스를 하나도 잠그지 않는 std::scoped_lock<>이고, 원래 뮤텍스 m1은 가려집니다. 실제로 이 줄 뒤에서 m1.lock()을 호출하면 no member named 'lock' in 'std::scoped_lock<>' 오류가 났습니다. 컴파일 오류로 드러나면 다행이지만, m1을 쓰지 않는 코드에서는 잠금이 걸리지 않은 채 조용히 지나갑니다.
실전 예시
예시 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이 막아 주는 것은 서로 다른 뮤텍스 사이의 순서 문제뿐입니다. std::scoped_lock lock(m, m);처럼 직접 같은 뮤텍스를 두 번 넘겨도 마찬가지입니다. std::recursive_mutex라면 재진입이 허용되지만, 설계로 막는 편이 낫습니다. 실제 코드에서는 함수 첫 줄에 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 m1, m2;
void func(bool needBoth) {
if (needBoth) {
std::scoped_lock lock(m1, m2);
// ...
} else {
std::scoped_lock lock(m1);
// ...
}
}자주 발생하는 문제
이름 없는 임시 객체와 빈 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 검사가 첫 번째 경우를 잡아 줍니다.
이동 불가
std::scoped_lock lock(mtx);
// 이동 불가
// auto lock2 = std::move(lock);
// unique_lock 사용 필요
std::unique_lock<std::mutex> ulock(mtx);
auto ulock2 = std::move(ulock); // OKC++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);
}두 방식은 같은 목적을 가집니다. std::lock(m1, m2)는 교착 상태를 피하는 알고리즘으로 두 뮤텍스를 모두 잠그고, 이미 잠긴 뮤텍스를 std::adopt_lock으로 lock_guard에 넘겨 해제만 맡깁니다. std::scoped_lock은 이 두 단계를 한 객체로 묶은 것입니다. C++11·14 환경에서는 scoped_lock이 없으므로 위의 std::lock + adopt_lock 조합을 써야 하고, 컴파일 옵션은 -std=c++17 이상이어야 합니다.
실무 패턴
패턴 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개 | 0개 이상 (가변 인자) | 1개 |
std::lock 다중 잠금 | 직접 조합 필요 | 내장 (std::lock 호출) | std::unique_lock + std::lock 패턴 |
수동 unlock / defer_lock | 불가 | 불가 | 가능 (defer_lock, try_to_lock 등) |
std::condition_variable과 함께 사용 | 불가 | 불가 | 가능 (wait가 unique_lock<mutex>를 요구) |
| 이동 | 불가 | 불가 | 가능 |
뮤텍스 하나를 블록 전체에서 잡는다면 lock_guard와 인자 하나짜리 scoped_lock 중 어느 쪽이든 됩니다. 스타일을 통일하려고 scoped_lock만 쓰는 팀도 있지만, 그 경우 앞에서 본 인자 누락 실수에 주의해야 합니다. 두 개 이상을 항상 같이 잠가야 한다면 scoped_lock이 가장 단순합니다. 중간에 잠금을 풀었다 다시 잡거나, 조건 변수로 대기하거나, try_lock_for처럼 타임아웃을 두고 시도해야 한다면 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를 따로 잠그는 경우.scoped_lock경로는 안전해도, 따로 잠그는 경로끼리 순서가 엇갈리면 그 둘 사이에서 데드락이 납니다. - 락 없이 공유 자료를 읽고, 다른 곳에서는 락을 잡고 쓰는 혼합 사용.
- 콜백·가상 함수 안에서 모르는 사이 다른 락을 잡는 비재진입(non-reentrant) 뮤텍스 중첩.
실무에서는 “전역 순서 번호”를 자원에 매기고, 항상 번호가 작은 뮤텍스부터 잠그는 규칙과 scoped_lock을 같이 쓰면 이해와 검증이 쉬워집니다. scoped_lock이 한 번에 잠그는 경로는 이 규칙 없이도 안전하지만, 뮤텍스를 따로따로 잠글 수밖에 없는 경로까지 같은 규칙으로 검증할 수 있고 코드 리뷰에서 잠금 경로를 따라가기도 쉬워집니다.
직접 확인한 교착 실험
“순서가 다르면 교착한다”는 설명이 실제로 어떻게 나타나는지 확인했습니다. 두 스레드가 같은 뮤텍스 두 개를 서로 반대 순서로 잠그는 코드를 만들었습니다. 교착이 나면 프로그램이 멈춰 버리므로, 개별 잠금 쪽은 std::timed_mutex와 try_lock_for(50ms)를 써서 “50ms 안에 못 잠근 횟수”를 셌습니다. 잠금 사이에 1ms를 쉬게 해서 두 스레드가 서로의 뮤텍스를 잡을 틈을 일부러 넓혔습니다.
#include <mutex>
#include <thread>
#include <chrono>
#include <iostream>
#include <atomic>
using namespace std::chrono_literals;
std::timed_mutex a, b;
std::atomic<int> timeouts{0};
void naive(std::timed_mutex& x, std::timed_mutex& y){
for(int i=0;i<200;i++){
if(!x.try_lock_for(50ms)){timeouts++;continue;}
std::this_thread::sleep_for(1ms);
if(!y.try_lock_for(50ms)){timeouts++; x.unlock(); continue;}
y.unlock(); x.unlock();
}
}
int main(){
std::thread t1(naive,std::ref(a),std::ref(b)), t2(naive,std::ref(b),std::ref(a));
t1.join(); t2.join();
std::cout<<"순서가 반대인 개별 잠금: 200회씩 시도 중 타임아웃 "<<timeouts<<"회\n";
std::mutex m1,m2; int done=0;
auto good=[&](std::mutex& x,std::mutex& y){ for(int i=0;i<200;i++){ std::scoped_lock lk(x,y); std::this_thread::sleep_for(1ms); done++; } };
std::thread u1(good,std::ref(m1),std::ref(m2)), u2(good,std::ref(m2),std::ref(m1));
u1.join(); u2.join();
std::cout<<"scoped_lock(x,y)를 반대 순서로 호출: "<<done<<"/400회 완료, 교착 없음\n";
}macOS arm64, Apple clang 21.0.0, -O2에서 두 번 실행한 결과는 둘 다 같았습니다.
순서가 반대인 개별 잠금: 200회씩 시도 중 타임아웃 399회
scoped_lock(x,y)를 반대 순서로 호출: 400/400회 완료, 교착 없음400번의 시도 중 399번이 50ms를 기다린 끝에 포기했습니다. 한쪽이 먼저 x를 잡고 1ms를 쉬는 동안 다른 쪽이 자기 x(상대의 y)를 잡기 때문입니다. 반면 std::scoped_lock(x, y)는 같은 반대 순서로 400번을 호출해도 모두 완료됐습니다. 이 실험은 잠금 사이에 쉬는 시간을 넣어 교착이 거의 항상 일어나게 만든 것이라, 실제 서비스에서 얼마나 자주 일어나는지를 보여 주는 수치는 아닙니다. 순서가 다르면 교착할 수 있고 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·언락·재시도를 하므로, 최선 경로(한 번에 모두 잠김)보다 약간 더 나쁠 수 있습니다. 그 대신 데드락 없음이라는 비용으로 보는 것이 맞습니다. - 벤치마크 시 주의: 나노초 단위로만 비교하기보다, 실제 임계 구역 길이·경쟁 스레드 수에서 전체 응답 시간을 재는 편이 의미 있습니다.