C++ in RTOS — RAII·std::thread·ETL·Coroutine

#한 줄 요약

“RTOS C++ = C API + RAII + 제한된 STL입니다.” — heap과 exception을 피하고 scope-based 자원 관리만으로도 안전성을 크게 높일 수 있습니다.

#어떤 문제를 푸는가

FreeRTOS, Zephyr, ThreadX 같은 RTOS의 공개 API는 C 함수입니다. mutex를 잡으면 반드시 풀고, queue handle을 만들면 반드시 해제해야 합니다. 짝을 빠뜨리면 deadlock 또는 자원 leak이 발생합니다.

C에서는 이 짝맞춤을 개발자가 매번 손으로 한다는 점이 가장 큰 위험입니다. 한 함수에 return path가 다섯 개라면 unlock도 다섯 곳에 적어야 하고, 새 path를 추가할 때 하나만 빠뜨려도 조용히 자원이 새기 시작합니다.

C++가 RTOS에 들어오는 첫 번째 가치는 RAII입니다. MutexGuard 같은 객체 하나만 도입해도, 함수가 어떻게 끝나든 소멸자가 unlock을 보장합니다. 두 번째 가치는 type-safe template입니다. xQueueCreate가 void pointer로 다루던 메시지가 StaticQueue<Cmd, 16>처럼 type을 보존한 채 안전하게 다뤄집니다.

다만 RTOS는 heap 사용 제한, 결정성 요구, code size 제약이라는 환경 안에서 동작합니다. 표준 C++가 가진 모든 기능을 그대로 쓸 수는 없고, 어떤 것을 쓰고 어떤 것을 피할지에 대한 판단이 필요합니다. 이번 편은 그 경계선을 정리합니다.

#RAII MutexGuard — 가장 작은 출발점

1
class MutexGuard {
2
public:
3
    explicit MutexGuard(SemaphoreHandle_t mtx,
4
                        TickType_t timeout = portMAX_DELAY)
5
        : mtx_(mtx),
6
          locked_(xSemaphoreTake(mtx, timeout) == pdTRUE) {}
7

8
    ~MutexGuard() {
9
        if (locked_) {
10
            xSemaphoreGive(mtx_);
11
        }
12
    }
13

14
    bool locked() const noexcept { return locked_; }
15

16
    MutexGuard(const MutexGuard&)            = delete;
17
    MutexGuard& operator=(const MutexGuard&) = delete;
18

19
private:
20
    SemaphoreHandle_t mtx_;
21
    bool              locked_;
22
};

-fno-exceptions 환경에서도 안전합니다. RAII는 exception unwinding에만 의존하는 메커니즘이 아니라 scope exit 시 소멸자 호출이 본질이기 때문입니다. return으로 빠져 나가든, break로 빠져 나가든, 마지막 }에 도달하든 소멸자는 호출됩니다.

1
void handle_command(void) {
2
    MutexGuard lock(state_mtx_, pdMS_TO_TICKS(10));
3
    if (!lock.locked()) {
4
        log_timeout();
5
        return;                   /* 자동 give 없음 — locked_ == false */
6
    }
7

8
    if (state_ == State::Idle) {
9
        return;                   /* 자동 give */
10
    }
11
    process_state(state_);
12
    /* 자동 give */
13
}

복사를 = delete로 막은 점이 중요합니다. 복사가 허용되면 같은 mutex가 두 번 give되어 카운트가 깨집니다.

#ScopedIRQDisable — Critical Section RAII

ISR과 데이터를 공유하는 짧은 critical section도 같은 패턴으로 묶습니다.

1
class ScopedIRQDisable {
2
public:
3
    ScopedIRQDisable() noexcept : primask_(__get_PRIMASK()) {
4
        __disable_irq();
5
    }
6
    ~ScopedIRQDisable() noexcept {
7
        __set_PRIMASK(primask_);
8
    }
9

10
    ScopedIRQDisable(const ScopedIRQDisable&)            = delete;
11
    ScopedIRQDisable& operator=(const ScopedIRQDisable&) = delete;
12

13
private:
14
    uint32_t primask_;
15
};
16

17
void update_shared(void) {
18
    ScopedIRQDisable irq_off;
19
    counter_++;
20
    if (counter_ > kMax) {
21
        counter_ = 0;
22
        flag_    = true;
23
    }
24
    /* 자동 enable */
25
}

진입 시점의 PRIMASK를 저장했다가 복원하므로 이미 disabled인 nested context에서도 안전합니다. 자세한 RAII 일반론은 Embedded C++ 2-01에서 다룹니다.

#std::lock_guard와 호환되는 Mutex Wrapper

RAII guard를 직접 만들지 않고 표준 std::lock_guard를 그대로 쓰는 방법이 있습니다. 직접 만들어야 할 것은 BasicLockable 컨셉을 만족하는 mutex 클래스뿐입니다.

1
class Mutex {
2
public:
3
    Mutex() : mtx_(xSemaphoreCreateMutex()) {
4
        configASSERT(mtx_ != nullptr);
5
    }
6
    ~Mutex() {
7
        vSemaphoreDelete(mtx_);
8
    }
9

10
    void lock()      { xSemaphoreTake(mtx_, portMAX_DELAY); }
11
    bool try_lock()  { return xSemaphoreTake(mtx_, 0) == pdTRUE; }
12
    void unlock()    { xSemaphoreGive(mtx_); }
13

14
    Mutex(const Mutex&)            = delete;
15
    Mutex& operator=(const Mutex&) = delete;
16

17
private:
18
    SemaphoreHandle_t mtx_;
19
};
20

21
/* 사용 — STL guard를 그대로 활용 */
22
Mutex state_mtx;
23

24
void task(void) {
25
    std::lock_guard<Mutex> lock(state_mtx);
26
    do_work();
27
}

이 wrapper의 진짜 가치는 코드가 표준 C++ 관용구로 표현된다는 점입니다. 새 팀원이 와도 std::lock_guard라는 익숙한 RAII 도구를 그대로 읽으면 됩니다. 내부가 FreeRTOS인지 Zephyr인지는 별로 중요하지 않게 됩니다.

#std::thread vs xTaskCreate — 결정성의 차이

std::thread는 표준 C++ thread API이지만, 임베디드 RTOS에서 그대로 쓰기에는 잘 맞지 않습니다. 이유 셋입니다.

첫째, std::thread의 구현은 보통 pthread 위에 얹혀 있습니다. RTOS에 pthread layer를 추가해야 동작하고, 그 layer 자체가 heap을 쓰고 control block 크기가 커지는 경향이 있습니다.

둘째, stack 크기와 priority를 생성 시점에 명시적으로 지정할 수 없습니다. 표준 std::thread의 생성자는 entry function과 인자만 받습니다. priority가 모두 같고 stack 크기를 컴파일러 default에 맡기는 형태가 됩니다. 임베디드에서는 priority와 stack 크기가 곧 시스템 설계인데 이것을 잃게 됩니다.

셋째, std::thread 객체가 RAII로 자기 thread를 join하거나 detach하려고 합니다. 임베디드 task는 보통 영원히 도는 무한 루프인데 std::thread의 소멸자가 호출되면 std::terminate가 호출됩니다.

결정적인 시스템에서는 xTaskCreate 또는 k_thread_create를 명시적으로 호출하는 편이 정직합니다.

1
class TaskBase {
2
public:
3
    TaskBase(const char *name, void (*entry)(void*), void *arg,
4
             configSTACK_DEPTH_TYPE stack_words, UBaseType_t prio) {
5
        BaseType_t r = xTaskCreate(entry, name, stack_words, arg, prio, &handle_);
6
        configASSERT(r == pdPASS);
7
    }
8
    ~TaskBase() {
9
        if (handle_ != nullptr) {
10
            vTaskDelete(handle_);
11
        }
12
    }
13
    TaskHandle_t handle() const { return handle_; }
14

15
    TaskBase(const TaskBase&)            = delete;
16
    TaskBase& operator=(const TaskBase&) = delete;
17

18
private:
19
    TaskHandle_t handle_ = nullptr;
20
};

std::thread 인터페이스를 강제로 흉내내기보다 RTOS API의 진짜 모양을 C++에 노출하는 wrapper가 사용성과 결정성을 모두 살립니다.

#Static Queue Template — Type Safety + No Heap

xQueueCreate는 void pointer 기반이라 송신과 수신에서 타입을 직접 맞춰야 합니다. template으로 감싸면 컴파일러가 검사해 줍니다.

1
template <typename T, size_t N>
2
class StaticQueue {
3
public:
4
    StaticQueue() {
5
        handle_ = xQueueCreateStatic(N, sizeof(T), storage_, &buf_);
6
        configASSERT(handle_ != nullptr);
7
    }
8

9
    bool push(const T& v, TickType_t timeout = portMAX_DELAY) {
10
        return xQueueSend(handle_, &v, timeout) == pdTRUE;
11
    }
12
    bool pop(T& v, TickType_t timeout = portMAX_DELAY) {
13
        return xQueueReceive(handle_, &v, timeout) == pdTRUE;
14
    }
15

16
    StaticQueue(const StaticQueue&)            = delete;
17
    StaticQueue& operator=(const StaticQueue&) = delete;
18

19
private:
20
    StaticQueue_t buf_;
21
    uint8_t       storage_[N * sizeof(T)] __attribute__((aligned(alignof(T))));
22
    QueueHandle_t handle_;
23
};
24

25
struct Command { uint16_t op; uint16_t arg; };
26
StaticQueue<Command, 16> cmd_q;
27

28
void producer(void) {
29
    cmd_q.push(Command{0x01, 0x42});
30
}
31

32
void consumer(void) {
33
    Command c;
34
    if (cmd_q.pop(c, pdMS_TO_TICKS(100))) {
35
        handle(c);
36
    }
37
}

heap이 전혀 쓰이지 않습니다. storage가 클래스 멤버이고 정렬도 type에 맞춰 자동으로 잡힙니다.

#ETL — Embedded Template Library

std::vector, std::string, std::map은 거의 모든 RTOS 환경에서 heap을 동적으로 사용합니다. 그 결과 fragmentation이 누적되고 WCET 분석이 깨집니다.

ETL(Embedded Template Library, MIT license)은 STL과 인터페이스가 비슷하지만 모두 fixed-capacity, no heap, no exception인 컨테이너 모음입니다.

1
#include <etl/vector.h>
2
#include <etl/queue.h>
3
#include <etl/string.h>
4
#include <etl/map.h>
5

6
etl::vector<int, 100>            v;        /* 최대 100, 내부 storage */
7
etl::queue<Command, 16>          q;
8
etl::string<32>                  s = "hello";
9
etl::map<uint8_t, Sensor*, 8>    sensors;  /* key 최대 8개 */
10

11
v.push_back(42);
12

13
if (v.size() >= v.capacity()) {
14
    /* heap 확장 없음, 호출자가 결정 */
15
}

API가 STL과 매우 닮아 있어 기존 C++ 코드의 사고방식을 그대로 가져올 수 있습니다. 결정적으로, 동작은 전부 stack 또는 static입니다. 자세한 ETL 활용은 Embedded C++ 4-02에서 다룹니다.

#컴파일러 플래그 — RTTI와 Exception

1
arm-none-eabi-g++ -std=c++20 -O2 \
2
    -fno-rtti \
3
    -fno-exceptions \
4
    -fno-threadsafe-statics

세 플래그가 RTOS C++의 표준 조합입니다.

-fno-rtti는 dynamic_cast와 typeid를 제거합니다. virtual class마다 따라붙던 RTTI 메타데이터가 사라져 코드 크기 ~10% 절약과 결정성 개선을 얻습니다.

-fno-exceptions는 throw/try/catch를 제거합니다. exception unwinding table이 사라져 추가 1020% 코드 절약과 WCET 분석 가능성을 얻습니다. 단, 표준 라이브러리 일부 함수가 exception throw로 실패를 보고하므로 (std::vector::at, std::stoi) 그런 API는 피하거나 대체합니다.

-fno-threadsafe-statics는 함수 내 static 객체 초기화의 thread-safe wrapper(__cxa_guard_acquire)를 제거합니다. RTOS task가 한 함수의 첫 호출에서 경쟁할 가능성이 없거나 직접 초기화 시점을 통제한다면 안전합니다.

#std::atomic — Cortex-M에서의 동작

1
#include <atomic>
2

3
std::atomic<int> counter{0};
4

5
void isr_handler(void) {
6
    counter.fetch_add(1, std::memory_order_relaxed);
7
}
8

9
void task(void) {
10
    int v = counter.load(std::memory_order_acquire);
11
    process(v);
12
}

Cortex-M3 이상은 LDREX/STREX 명령으로 lock-free atomic을 hardware로 지원합니다. C++ 표준 std::atomic<T>는 T가 word 크기(32-bit)이면 lock-free입니다.

std::atomic<int64_t>처럼 word를 넘는 type은 32-bit 시스템에서 lock-based가 됩니다. ARMv7-M은 LDREXD/STREXD로 64-bit lock-free를 지원하지만, 컴파일러가 자동으로 이 명령을 emit하는지는 옵션에 달려 있습니다. is_lock_free()를 컴파일 타임에 확인합니다.

#C++20 Coroutine — RTOS 위의 Async

C++20 coroutine은 stackless 비동기 단위입니다. RTOS task 위에서 여러 async 흐름을 표현할 때 유용합니다.

1
#include <coroutine>
2

3
struct Task {
4
    struct promise_type {
5
        Task get_return_object() { return {}; }
6
        std::suspend_never initial_suspend() noexcept { return {}; }
7
        std::suspend_never final_suspend()  noexcept { return {}; }
8
        void return_void() {}
9
        void unhandled_exception() {}
10
    };
11
};
12

13
struct Delay {
14
    TickType_t ticks;
15
    bool await_ready() const noexcept { return false; }
16
    void await_suspend(std::coroutine_handle<> h) const {
17
        schedule_resume_after(h, ticks);    /* RTOS timer로 resume */
18
    }
19
    void await_resume() const noexcept {}
20
};
21

22
Task blink_task(GPIO_TypeDef *port, uint16_t pin) {
23
    while (true) {
24
        port->BSRR = pin;
25
        co_await Delay{pdMS_TO_TICKS(500)};
26
        port->BSRR = (uint32_t)pin << 16;
27
        co_await Delay{pdMS_TO_TICKS(500)};
28
    }
29
}

coroutine frame은 컴파일러가 생성한 작은 구조체이며 한 task의 stack과는 별도로 promise type이 지정한 allocator에서 할당됩니다. RTOS에서는 pool allocator를 promise에 묶어 heap fragmentation을 피하는 패턴이 일반적입니다.

핵심은 한 task에서 여러 coroutine을 cooperative하게 돌릴 수 있다는 점입니다. 한 task 안의 여러 상태 머신을 별도 sub-task로 만들지 않아도 됩니다.

#Virtual Function의 비용

virtual function 호출은 vtable lookup → indirect call로 평범한 함수 호출보다 약간 비쌉니다.

Cortex-M4 @ 168 MHz, hot cache

ISR 진입 직후 호출되는 hot path라면 concrete type을 직접 호출하거나 static polymorphism(CRTP) 으로 대체하는 편이 결정성에 좋습니다. CRTP 패턴은 Embedded C++ 2-08에서 자세히 다룹니다.

1
template <typename Derived>
2
class SensorBase {
3
public:
4
    void sample() {
5
        static_cast<Derived*>(this)->read_impl();   /* compile-time bind */
6
    }
7
};
8

9
class Imu : public SensorBase<Imu> {
10
public:
11
    void read_impl() { /* MMIO read */ }
12
};

vtable이 사라지므로 직접 call로 inlining되고 RTTI 메타데이터도 필요 없습니다.

#자주 보는 함정과 안티패턴

경고 — heap-backed STL을 RTOS에서 그대로 사용

1
std::vector<Cmd> queue;        /* heap, fragmentation */
2
queue.push_back(c);

장시간 동작 후 fragmentation으로 malloc 실패가 발생할 수 있습니다. etl::vector<Cmd, N> 또는 StaticQueue<Cmd, N>로 대체합니다.

경고 — 소멸자에서 예외

1
~UartGuard() {
2
    if (deinit() < 0) throw std::runtime_error("...");
3
}

소멸자에서 예외를 던지면 stack unwinding 중 std::terminate가 호출됩니다. -fno-exceptions에서도 abort로 이어지므로 소멸자는 항상 noexcept이고 실패는 조용히 처리하거나 로깅합니다.

경고 — Static initialization order fiasco

1
Sensor g_sensor;
2

3
/* logger.cpp */
4
extern Sensor g_sensor;
5
Logger g_logger(g_sensor);     /* g_sensor 초기화 전일 수 있음 */

translation unit 사이의 전역 객체 초기화 순서는 보장되지 않습니다. construct-on-first-use idiom을 사용합니다.

1
Sensor& sensor() {
2
    static Sensor s;            /* 첫 호출 시 1회 초기화 */
3
    return s;
4
}

-fno-threadsafe-statics를 쓰는 경우 첫 호출이 단일 task에서만 일어남을 설계자가 보장해야 합니다.

경고 — ISR에서 heap allocation

1
void TIM2_IRQHandler(void) {
2
    auto evt = std::make_unique<Event>(...);    /* malloc in ISR */
3
    queue.push(std::move(evt));
4
}

malloc이 spinlock을 잡는 구현이라면 ISR 안에서 hang할 수 있고, 그렇지 않더라도 WCET 분석이 깨집니다. ISR이 쓰는 객체는 static 또는 pool에서 미리 확보합니다.

경고 — 거대한 template 인스턴스화

1
StaticQueue<HugeStruct, 16384> q;

같은 template이 여러 type에 대해 인스턴스화되면 code bloat가 누적됩니다. 공통 로직은 non-template base class로 빼고 template은 얇은 wrapper로 두는 패턴이 안전합니다.

#RAII Overhead 측정

같은 mutex critical section을 C 수동 코드와 C++ RAII로 비교합니다(ARM Cortex-M4, -O2, FreeRTOS).

1
# C 수동
2
shared:
3
    push    {r4, lr}
4
    bl      xSemaphoreTake
5
    ldr     r3, [counter]
6
    adds    r3, r3, #1
7
    str     r3, [counter]
8
    bl      xSemaphoreGive
9
    pop     {r4, pc}
10
# 24 bytes
11

12
# C++ RAII (MutexGuard)
13
shared:
14
    push    {r4, lr}
15
    bl      xSemaphoreTake
16
    ldr     r3, [counter]
17
    adds    r3, r3, #1
18
    str     r3, [counter]
19
    bl      xSemaphoreGive
20
    pop     {r4, pc}
21
# 24 bytes — 동일

생성자와 소멸자가 모두 inlining되어 overhead가 0입니다. 전형적인 zero-cost abstraction입니다.

#MISRA C++ / AUTOSAR C++14 — 안전 표준

MISRA C++ 2008 / 2023

• exception 사용 제한
• dynamic dispatch 제한
• template metaprogramming 제한

AUTOSAR C++14 Coding Guidelines

• 현대 C++ 일부 허용 (constexpr, auto, lambda)
• 자동차 safety-critical에 적합

JSF C++ (Lockheed Martin F-35) — 가장 보수적, F-35 비행 소프트웨어용.

이런 표준은 ETL과 잘 어울립니다. heap, exception, dynamic dispatch가 모두 제거된 상태에서 RAII와 template으로만 안전성을 표현하므로 분석 가능성과 결정성을 동시에 얻습니다. 자세한 소유권 모델은 Embedded C++ 3-10에서 다룹니다.

#정리

• RTOS C++의 출발점은 RAII로 C API의 짝맞춤을 자동화하는 것이며, MutexGuard와 ScopedIRQDisable이 가장 작은 시작점입니다.
• 표준 std::lock_guard를 그대로 쓰려면 BasicLockable 컨셉만 만족하는 Mutex wrapper를 만들면 됩니다.
• std::thread는 pthread layer, stack/priority 표현 부족, 소멸자 동작 차이 때문에 임베디드 RTOS에서 그대로 쓰기에 부적합합니다. xTaskCreate를 명시적으로 호출하는 thin wrapper가 정직합니다.
• StaticQueue<T, N> 같은 template은 type safety와 no-heap을 동시에 제공합니다.
• 표준 STL container는 heap을 쓰므로 ETL의 fixed-capacity container로 대체합니다.
• RTOS 빌드의 표준 컴파일러 옵션은 -fno-rtti -fno-exceptions -fno-threadsafe-statics입니다.
• std::atomic은 word 크기 type에 대해 Cortex-M3+에서 lock-free이며, ISR과 task 사이 카운터에 자연스럽게 쓰입니다.
• C++20 coroutine은 한 task 안의 여러 async 흐름을 stackless로 표현하는 도구로 활용 가치가 큽니다.
• virtual function은 hot path에서 측정 가능한 비용이 있으며, CRTP 같은 static polymorphism으로 대체 가능합니다.
• 소멸자 예외, static initialization order, ISR 안 heap allocation이 가장 자주 보는 함정입니다.

다음 part는 Part 5에서 RTOS porting과 시스템 통합 사례를 다룹니다.

#관련 항목

• 4-12: AMP와 OpenAMP
• Embedded C++ 2-01: RAII 기초
• Embedded C++ 2-08: Static Polymorphism (CRTP)
• Embedded C++ 3-10: 소유권 모델
• Embedded C++ 4-02: ETL Library