해설 — 거래 도중 한쪽이 로그아웃/접속종료되어 롤백이 필요한 상황 (C++)

난이도: 상

답변 프레임워크: 요약 → 문제 분류 → 원인 → 수정안 → 더 나은 설계

요약

onConfirm(commit)과 onDisconnect(취소)가 공유 거래 상태를 락 없이 플래그만으로 조율한다. (C) 둘 다 !t.committed 를 검사하고 행동하는 check-then-act 라, commit 진행 중 다른 스레드의 onDisconnect 가 취소에 들어가 commit 과 취소가 동시에 일어난다. 더 치명적으로 C++ 에서는 onDisconnect 가 trades_.erase(it) 로 거래 노드를 파괴하는데, commit 은 같은 노드를 TradeSession& t 참조로 들고 자산 이동 중이라 use-after-free 가 된다(반대로 commit 의 마지막 trades_.erase 이후 t 사용도 UAF). (B) commit 의 교환이 "아이템들→골드" 를 비원자 로 적용하고 반환값을 무시해, 중간 실패/세션 정리 시 부분 적용(증발/복제)으로 끝난다. (A) commit 진입 가드가 단순 플래그라 이중 commit 가능. 정답 한 줄: 거래를 shared_ptr + 상태기계로 관리하고, 거래 락 안에서 commit↔취소를 상호배제하며, 두 플레이어 인벤토리를 고정 순서로 락(std::scoped_lock)해 선검증→all-or-nothing(또는 에스크로)으로 교환하라.

변별: content_gamelogic/problem3(두 거래자 교환 경합/원자성)와 달리, 본 간판은 세션 종료가 commit 과 경합할 때의 조율 + 거래 객체 수명(UAF) + 부분 commit 롤백이다.

문제점

(C) commit vs 취소 비원자 + 거래 객체 UAF (동시성·메모리) ★간판

• 분류 태그: check-then-act / use-after-free.
• 증상: commit 이 TradeSession& t = it->second 로 노드를 들고 자산 이동 중인데, 다른 스레드의 onDisconnect 가 trades_.erase(it) 로 그 노드를 파괴 → t 가 댕글링되어 이후 접근이 UAF. 동시에 "교환은 절반 적용됐는데 거래는 취소로 삭제" 되어 롤백 경로도 사라진다. unordered_map::erase 는 해당 원소의 참조/반복자만 무효화하지만, 그 무효화가 바로 이 버그.
• 재현조건: confirm→commit 진입과 동시에 한쪽 disconnect.
• 근본 원인: 거래 객체 수명이 보호되지 않고(값 노드를 참조로 공유), commit/취소가 단일 임계구역·단일 상태 전이가 아니다.

(B) 비원자 자산 교환 — 부분 적용(복제/증발) (정합) ★간판

• 분류 태그: non-atomic multi-step / ignored return value / missing rollback.
• 증상: moveItem 들 → moveGold 들을 순차 적용하고 반환값을 무시. 중간에 한쪽 인벤토리가 정리되거나 moveGold 가 false 면 A는 아이템을 잃고 B는 골드를 안 줌.
• 근본 원인: 교환이 트랜잭션이 아님(선검증·all-or-nothing·롤백 부재).

(A) 이중 commit 가드 부실 (정합/동시성)

• 분류 태그: check-then-act.
• 증상: !t.committed 만 보고 commit. 두 스레드가 동시에 마지막 confirm 을 넣으면 둘 다 통과해 이중 이동.
• 근본 원인: commit 전이가 원자 1회로 보장되지 않음.

(참고) 데드락 / 맵 동시성

• 두 플레이어 인벤토리를 각각 락으로 보호한다면, 거래 방향에 따라 (A락→B락)/(B락→A락) 순서가 엇갈려 AB-BA 데드락이 날 수 있다. 또한 trades_/playerToTrade_ 동시 접근 자체가 레이스.

수정안

핵심: 거래를 shared_ptr 로 수명 보장 + 거래별 mutex/상태기계 + 두 플레이어 락 고정순서.

#include <memory>
#include <mutex>
#include <algorithm>

enum class TradeState { Pending, Committing, Committed, Cancelled };

struct TradeSession {
    int64_t tradeId;
    TradeOffer a, b;
    TradeState state = TradeState::Pending;
    std::mutex gate;
};

class TradeService {
public:
    explicit TradeService(Inventory& inv) : inv_(inv) {}

    void onConfirm(int64_t tradeId, int64_t playerId) {
        std::shared_ptr<TradeSession> t;
        { std::lock_guard<std::mutex> mg(mapMu_);
          auto it = trades_.find(tradeId); if (it == trades_.end()) return; t = it->second; }

        bool doCommit = false;
        {
            std::lock_guard<std::mutex> g(t->gate);
            if (t->state != TradeState::Pending) return;          // 취소/완료엔 무시
            if (playerId == t->a.playerId) t->a.confirmed = true;
            else if (playerId == t->b.playerId) t->b.confirmed = true;
            else return;
            if (t->a.confirmed && t->b.confirmed) { t->state = TradeState::Committing; doCommit = true; }
        }
        if (doCommit) commit(t);                                   // shared_ptr 로 수명 보장
    }

    void onDisconnect(int64_t playerId) {
        std::shared_ptr<TradeSession> t;
        { std::lock_guard<std::mutex> mg(mapMu_);
          auto pit = playerToTrade_.find(playerId); if (pit == playerToTrade_.end()) return;
          auto it = trades_.find(pit->second); if (it == trades_.end()) return; t = it->second; }

        {
            std::lock_guard<std::mutex> g(t->gate);
            if (t->state == TradeState::Committing || t->state == TradeState::Committed) return; // commit 경로 보호
            t->state = TradeState::Cancelled;                     // Pending 만 취소
        }
        cleanup(t);   // 에스크로면 반납; 단계적용이면 아직 아무것도 안 옮겼으므로 정리만
    }

private:
    void commit(const std::shared_ptr<TradeSession>& t) {
        int64_t lo = std::min(t->a.playerId, t->b.playerId);
        int64_t hi = std::max(t->a.playerId, t->b.playerId);
        {
            std::scoped_lock lk(inv_.lockFor(lo), inv_.lockFor(hi));  // 고정순서 동시 락 → 데드락 회피
            if (!inv_.canMoveAll(t->a) || !inv_.canMoveAll(t->b)) { cancel(t); return; }
            if (!inv_.applyAtomic(t->a, t->b)) { cancel(t); return; } // 실패 시 롤백
        }
        { std::lock_guard<std::mutex> g(t->gate); t->state = TradeState::Committed; }
        eraseFromMaps(t);
    }
    // cancel/cleanup/eraseFromMaps: mapMu_ 아래에서 trades_/playerToTrade_ 정리 (shared_ptr 라 사용 중이면 살아있음)

    Inventory& inv_;
    std::mutex mapMu_;
    std::unordered_map<int64_t, std::shared_ptr<TradeSession>> trades_;
    std::unordered_map<int64_t, int64_t> playerToTrade_;
};

포인트

• shared_ptr<TradeSession> 를 맵에 보관하고 작업 전 복사해 쥐면, 다른 스레드가 맵에서 지워도 객체는 살아 있어 UAF 제거.
• state 전이를 gate 락 안에서 단일화 → commit(Committing)·취소(Cancelled)는 둘 중 하나만.
• std::scoped_lock(lockFor(lo), lockFor(hi)) 로 두 인벤토리를 고정순서·동시 락 → AB-BA 데드락 회피, 그 안에서 canMoveAll(선검증)→applyAtomic(실패 시 롤백)으로 all-or-nothing.
• 맵 접근은 mapMu_ 로 보호.

더 나은 설계 (+트레이드오프)

1. 에스크로 + 2단계: 확정=에스크로 입고, commit=배분, 취소/끊김=반납. 어느 시점에 끊겨도 자산이 정확히 한 곳에 존재. 트레이드오프: 에스크로 저장/정리 잡.
2. 영속 트랜잭션/사가: 교환을 단일 DB 트랜잭션 또는 보상 트랜잭션으로 → 크래시·다중 서버 안전. 트레이드오프: 지연/복잡도.
3. 접속종료 grace: 순간 끊김에 즉시 취소하지 않고 짧게 freeze. 트레이드오프: 자산 잠금/타임아웃.
4. 멱등 commit 키(tradeId): 재시도/중복에도 1회만 적용.

면접 포인트 (예상 질문)

1. TradeSession& 를 들고 자산을 옮기는 중 다른 스레드가 맵에서 erase 하면 왜 UAF 인가? shared_ptr 가 이를 어떻게 막는가?
2. 순차 moveItem/moveGold + 반환값 무시가 어떤 부분 적용(복제/증발)을 만드는가? 에스크로가 왜 더 안전한가?
3. 두 플레이어 인벤토리 락에서 AB-BA 데드락을 std::scoped_lock/고정순서로 어떻게 피하는가?