禁用/恢复中断的C++类替代宏方案：编译器能否正确调用构造与析构？

背景与问题 #

我之前习惯用一对宏来实现禁用中断的原子操作：

START_ATOMIC() do { bool ie = current_interrupt_state(); disable_interrupts()
END_ATOMIC() if (ie) { enable_interrupts(); } } while(0)

这个宏能保证成对使用，缺任一会触发编译错误。但出于编码标准中避免使用宏的要求，我改用了RAII风格的结构体实现：

struct Atomic
{
    /* 保存当前中断状态并禁用中断 */
    Atomic() : ie_(int_disable()) {}

    /* 恢复中断原始状态 */
    ~Atomic()
    {
        if (ie_)
        {
            int_enable();
        }
    }

private:
    bool ie_;
};

使用时在代码块中声明对象，临界操作放在块内：

{
   Atomic start_critical_section;
   /* 此处执行禁用中断后的操作 */
}

构造函数负责保存状态并禁用中断，析构函数在离开代码块时自动恢复状态。我的核心疑问是：**编译器会不会不在正确的时机调用构造函数，尤其是析构函数？**我认为构造会在进入代码块时执行，临界操作在中间，析构在离开时执行，但不确定是否忽略了问题。

解答 #

核心结论 #

你的RAII思路完全正确，且比宏方案更安全、更符合现代C++规范，但volatile修饰符是多余甚至可能引发问题的，具体分析如下：

1. 构造/析构时机的可靠性

C++标准明确规定：

• 局部代码块中声明的自动对象，构造函数会在进入代码块后、第一条语句执行前被调用
• 析构函数会在退出代码块时、后续语句执行前被调用——无论正常走到块尾、通过return/break跳转，还是抛出异常（只要程序未被std::terminate强制终止）

只要你在局部代码块中声明Atomic对象，编译器必须保留构造和析构的调用——因为这两个函数内部包含对硬件寄存器的操作（int_disable()/int_enable()本质是读写中断控制寄存器），属于有不可忽略副作用的函数调用，编译器不能随意优化掉。

2. volatile修饰符的问题

你添加volatile是担心编译器优化析构，但完全没必要：

• volatile的作用是告知编译器对象的值可能被外部（如硬件、中断）修改，需直接访问内存而非缓存，但你的Atomic对象的ie_仅在构造时初始化，后续无修改，volatile在这里起不到预期作用。
• 即使不加volatile，编译器也必须调用构造和析构，因为它们的副作用不可忽略。正确的做法是给int_disable()和int_enable()添加编译器属性（如GCC的__attribute__((used))）或[[nodiscard]]标记，明确告知编译器这些函数有副作用不能被优化。

3. 相较于宏方案的优势

• 自动配对：只要对象在代码块内，析构一定会执行，不会像宏那样因手误漏写END_ATOMIC()导致中断无法恢复。
• 异常安全：若临界区抛出异常（假设环境支持异常），宏方案会导致中断永久禁用，而RAII方案的析构会自动触发，恢复中断状态。
• 类型安全：宏是文本替换，易出现语法错误；结构体是类型安全的，编译器会自动检查错误。

4. 需注意的细节

• 确保int_disable()正确返回当前中断状态（即禁用前中断是否开启），int_enable()能准确恢复该状态。
• 不要将Atomic对象声明为全局或静态变量，否则构造/析构时机不受你控制。
• 若为裸机嵌入式环境，需确认编译器优化（如-O2）不会误删有副作用的函数调用——可给int_disable()和int_enable()添加__attribute__((noinline))等属性加固。

内容的提问来源于stack exchange，提问作者Giancarlo