해설 — 우편 회수와 수령의 동시 처리 (이중 지급 / 이중 유실)

난이도: 중

요약

Recall 과 Claim 은 각각 "포인터로 레코드를 찾는다 → 상태를 검사한다 → 지급한다 → 상태를 바꾼다"는 네 단계를 별도의 동기화 없이 수행한다. MailStore::Find 가 반환하는 MailRecord* 는 호출자에게 원본 데이터에 대한 공유 가변 접근을 그대로 열어주는데, 두 워커 스레드가 같은 mailId 에 대해 동시에 Recall/Claim 을 호출하면 (A)와 (B)의 상태 검사가 서로의 쓰기를 보지 못한 채 통과해버려 골드가 두 번 지급될 수 있다. 또한 이 코드는 멀티스레드 접근에 대한 어떤 락도 갖고 있지 않아, 상태 필드 자체의 읽기/쓰기가 데이터 레이스이며 unordered_map 을 여러 스레드가 동시에 변형(리해시 등)할 경우 정의되지 않은 동작으로 이어질 수 있다.

문제점

• 분류: 비원자 검사-처리(check-then-act) / 공유 가변 상태에 대한 동기화 부재
• 증상: 회수 요청과 수령 요청이 거의 동시에 서로 다른 워커 스레드에서 실행되면, 둘 다 mail->state == MailState::Sent 인 시점을 관측해 검사를 통과하고 각자 골드를 지급한 뒤 state 를 자신이 원하는 값으로 덮어쓴다 — 결과적으로 골드가 이중 지급되고, 최종 state 값은 나중에 실행된 쪽의 것으로 남아 먼저 지급이 일어났던 사실 자체가 기록에서 드러나지 않는다.
• 재현 조건: 같은 mailId 에 대해 스레드 T1 이 Recall, 스레드 T2 가 Claim 을 거의 동시에 호출하고, T1 의 (A) 검사와 T2 의 (B) 검사가 모두 T1/T2 어느 쪽의 state 쓰기도 아직 관측하지 못한 시점에 실행되는 경우.
• 근본 원인:
  • (A)/(B) 모두 Find 로 얻은 MailRecord* 를 통해 상태를 읽고 곧바로 그 판단에 따라 지급·쓰기를 수행하는데, 이 전체 시퀀스를 보호하는 락이 전혀 없다. MailStore 와 Wallet 접근에 뮤텍스가 없으므로, "검사"와 "지급+쓰기" 사이의 창을 다른 스레드가 파고들 수 있다.
  • Find 가 내부 컨테이너의 원소를 가리키는 raw 포인터를 그대로 반환하는 설계도 위험을 키운다. 다른 스레드가 같은 unordered_map 에 동시에 Insert(리해시 유발 가능)를 수행하면, 이미 받아둔 포인터가 무효화된 메모리를 가리키게 될 수 있다 — 상태 레이스에 더해 잠재적인 댕글링 포인터 접근 위험까지 겹친다.

수정안

우편 레코드 단위로 잠글 수 있는 뮤텍스를 두고, "검사-지급-상태전이" 전체를 하나의 임계 구역으로 묶어 원자화한다.

#include <cstdint>
#include <mutex>
#include <unordered_map>

enum class MailState { Sent, Claimed, Recalled };

struct MailRecord
{
    int64_t   mailId;
    uint64_t  senderId;
    uint64_t  receiverId;
    int64_t   attachedGold;
    MailState state;
};

class Wallet
{
public:
    void AddGold(uint64_t userId, int64_t amount)
    {
        std::lock_guard<std::mutex> lock(mutex_);
        balances_[userId] += amount;
    }

private:
    std::mutex mutex_;
    std::unordered_map<uint64_t, int64_t> balances_;
};

class MailStore
{
public:
    // 레코드별 뮤텍스를 함께 보관해 회수/수령 전체를 그 뮤텍스로 보호한다.
    struct Entry
    {
        MailRecord mail;
        std::mutex mutex;
    };

    Entry* Find(int64_t mailId)
    {
        std::lock_guard<std::mutex> lock(mapMutex_);
        auto it = table_.find(mailId);
        return it == table_.end() ? nullptr : &it->second;
    }

    void Insert(const MailRecord& mail)
    {
        std::lock_guard<std::mutex> lock(mapMutex_);
        table_[mail.mailId].mail = mail;
    }

private:
    std::mutex mapMutex_;                              // 컨테이너 구조 변경 보호
    std::unordered_map<int64_t, Entry> table_;
};

class MailService
{
public:
    MailService(MailStore* store, Wallet* wallet) : store_(store), wallet_(wallet) {}

    bool Recall(int64_t mailId, uint64_t requesterId)
    {
        MailStore::Entry* entry = store_->Find(mailId);
        if (!entry)
            return false;

        std::lock_guard<std::mutex> lock(entry->mutex);  // 검사~전이 전체를 원자화
        MailRecord& mail = entry->mail;
        if (mail.senderId != requesterId || mail.state != MailState::Sent)
            return false;

        wallet_->AddGold(mail.senderId, mail.attachedGold);
        mail.state = MailState::Recalled;
        return true;
    }

    bool Claim(int64_t mailId, uint64_t requesterId)
    {
        MailStore::Entry* entry = store_->Find(mailId);
        if (!entry)
            return false;

        std::lock_guard<std::mutex> lock(entry->mutex);  // Recall 과 동일한 락을 공유
        MailRecord& mail = entry->mail;
        if (mail.receiverId != requesterId || mail.state != MailState::Sent)
            return false;

        wallet_->AddGold(mail.receiverId, mail.attachedGold);
        mail.state = MailState::Claimed;
        return true;
    }

private:
    MailStore* store_;
    Wallet*    wallet_;
};

Find 는 이제 컨테이너 자체의 구조 변경(삽입으로 인한 리해시)으로부터는 짧은 mapMutex_ 로 보호되고, 반환된 Entry* 를 통한 상태 검사~전이는 레코드별 뮤텍스로 별도 보호된다. unordered_map 의 값 타입(Entry)이 노드 기반 컨테이너에 저장되는 한 참조/포인터는 삽입 후에도 안정적이므로, Find 호출 이후 락을 잡고 접근하는 동안 다른 스레드의 삽입이 있어도 댕글링 걱정 없이 안전하다.

더 나은 설계

• 레코드별 뮤텍스(채택안): 전역 락 하나로 모든 우편을 잠그는 것보다 경합이 훨씬 적다. 다만 레코드 수만큼 뮤텍스를 유지해야 하므로 메모리 오버헤드가 있고, 우편 삭제(만료 정리) 시점에 그 뮤텍스가 아직 다른 스레드에 의해 잠겨 있지 않은지 확인하는 생명주기 관리가 필요하다.
• DB 트랜잭션 + 조건부 UPDATE: 우편함이 영속 저장소(DB)에 있다면, UPDATE mail SET state='Claimed' WHERE mail_id=? AND state='Sent' 처럼 상태 전이 자체를 원자적 SQL 문으로 만드는 편이 인메모리 락보다 서버 재시작/다중 프로세스 환경에 더 견고하다. C++ 서버 프로세스가 여러 개 떠 있는 구성이라면 인메모리 뮤텍스만으로는 다른 프로세스의 동시 접근을 막지 못한다.
• shared_ptr + weak_ptr 로 레코드 소유권 명시: raw 포인터 대신 std::shared_ptr<Entry> 로 반환하면, 레코드가 삭제된 뒤에도 포인터가 남아있는 것을 방지하고 수명 관리가 명확해진다. 다만 참조 카운트 오버헤드와 순환 참조(리스너 등록 시) 주의가 추가로 필요하다.
• 트레이드오프: 단일 프로세스 인메모리 서버라면 레코드별 뮤텍스가 구현이 가장 단순하고 성능도 좋다. 다중 프로세스/샤드 구성이라면 결국 DB 또는 분산 락 수준의 원자성이 필요하므로, 인메모리 락은 DB 트랜잭션을 보완하는 캐시 레이어 최적화 정도로만 써야 한다.

면접 포인트

• 컨테이너에서 얻은 raw 포인터/참조를 락 없이 여러 스레드가 공유하면, "검사 후 처리" 시퀀스 전체가 원자적이지 않은 한 이중 지급·이중 유실 같은 논리적 결함으로 이어진다 — 이는 C++ 에서 메모리 안전성 문제(댕글링 포인터)와 별개로, 락 범위를 어디까지 잡아야 하는지의 문제임을 구분해서 설명할 수 있어야 한다.
• 컨테이너 재해시로 인한 반복자/포인터 무효화는 "노드 기반 컨테이너(unordered_map, map)는 삽입 후에도 기존 원소의 참조가 안정적"이라는 사실과 "컨테이너 구조 자체를 바꾸는 연산(삽입/삭제)은 동시 접근 시 여전히 보호가 필요하다"는 사실을 함께 알아야 정확히 판단할 수 있다.
• 레코드별 락과 전역 락(또는 DB 트랜잭션)의 트레이드오프 — 세분화된 락은 경합을 줄이지만 락 수명 관리와 데드락(여러 레코드를 동시에 잠그는 연산이 생길 경우 락 순서) 위험이 늘어난다는 점을 설명할 수 있어야 한다.