带有 `volatile` 数组的 `memcpy((void *)dest, src, n)` 安全吗？

Question

我有一个用于 UART 的缓冲区，它是这样声明的：

union   Eusart_Buff {
    uint8_t     b8[16];
    uint16_t    b9[16];
};

struct  Eusart_Msg {
    uint8_t             msg_posn;
    uint8_t             msg_len;
    union Eusart_Buff   buff;
};

struct  Eusart {
    struct Eusart_Msg   tx;
    struct Eusart_Msg   rx;
};

extern  volatile    struct Eusart   eusart;

这是填充缓冲区的函数（将使用中断发送）：

void    eusart_msg_transmit (uint8_t n, void *msg)
{

    if (!n)
        return;

    /*
     * The end of the previous transmission will reset
     * eusart.tx.msg_len (i.e. ISR is off)
     */
    while (eusart.tx.msg_len)
        ;

    if (data_9b) {
        memcpy((void *)eusart.tx.buff.b9, msg,
                sizeof(eusart.tx.buff.b9[0]) * n);
    } else {
        memcpy((void *)eusart.tx.buff.b8, msg,
                sizeof(eusart.tx.buff.b8[0]) * n);
    }
    eusart.tx.msg_len   = n;
    eusart.tx.msg_posn  = 0;

    reg_PIE1_TXIE_write(true);
}

在使用memcpy()的那一刻，我知道没有其他人会使用缓冲区（原子），因为while循环确保最后一条消息已经发送，因此中断被禁用。

以这种方式丢弃volatile 是否安全，以便我能够使用memcpy() 或者我应该创建一个可能称为memcpy_v() 的函数以确保安全？：

void *memcpy_vin(void *dest, const volatile void *src, size_t n)
{
    const volatile char *src_c  = (const volatile char *)src;
    char *dest_c                = (char *)dest;

    for (size_t i = 0; i < n; i++)
        dest_c[i]   = src_c[i];

    return  dest;
}

volatile void *memcpy_vout(volatile void *dest, const void *src, size_t n)
{
    const char *src_c       = (const char *)src;
    volatile char *dest_c   = (volatile char *)dest;

    for (size_t i = 0; i < n; i++)
        dest_c[i]   = src_c[i];

    return  dest;
}

volatile void *memcpy_v(volatile void *dest, const volatile void *src, size_t n)
{
    const volatile char *src_c  = (const volatile char *)src;
    volatile char *dest_c       = (volatile char *)dest;

    for (size_t i = 0; i < n; i++)
        dest_c[i]   = src_c[i];

    return  dest;
}

编辑：

如果我需要这些新功能， 鉴于我知道没有人会同时修改数组，使用restrict 来（也许）帮助编译器优化（如果可以的话）是否有意义？ 可能是这样（如果我错了，请纠正我）：

volatile void *memcpy_v(restrict volatile void *dest,
                        const restrict volatile void *src,
                        size_t n)
{
    const restrict volatile char *src_c = src;
    restrict volatile char *dest_c      = dest;

    for (size_t i = 0; i < n; i++)
        dest_c[i]   = src_c[i];

    return  dest;
}

编辑 2（添加上下文）：

void    eusart_end_transmission (void)
{

    reg_PIE1_TXIE_write(false); /* TXIE is TX interrupt enable */
    eusart.tx.msg_len   = 0;
    eusart.tx.msg_posn  = 0;
}

void    eusart_tx_send_next_c   (void)
{
    uint16_t    tmp;

    if (data_9b) {
        tmp     = eusart.tx.buff.b9[eusart.tx.msg_posn++];
        reg_TXSTA_TX9D_write(tmp >> 8);
        TXREG   = tmp;
    } else {
        TXREG   = eusart.tx.buff.b8[eusart.tx.msg_posn++];
    }
}

void __interrupt()  isr(void)
{

    if (reg_PIR1_TXIF_read()) {
        if (eusart.tx.msg_posn >= eusart.tx.msg_len)
            eusart_end_transmission();
        else
            eusart_tx_send_next_c();
    }
}

虽然 volatile 可能不需要 是需要（我在另一个问题中问过：volatile for variable that is only read in ISR?），这个仍然应该在需要volatile 的假设下回答问题，以便真正需要volatile 的未来用户（例如我在实现RX 缓冲区时）可以知道该怎么做。

---

编辑（相关）（7 月 19 日）：

volatile vs memory barrier for interrupts

基本上说volatile 是不需要的，因此这个问题就消失了。

Answer 1

memcpy((void *)dest, src, n) 和 volatile 数组是否安全？

没有。在一般情况下，memcpy() 未指定为与易失性内存一起正常工作。
OP 的案例看起来可以抛弃volatile，但发布的代码不足以确定。

如果代码想memcpy()volatile内存，写辅助函数。

OP 的代码有 restrict 在错误的位置。建议

volatile void *memcpy_v(volatile void *restrict dest,
            const volatile void *restrict src, size_t n) {
    const volatile unsigned char *src_c = src;
    volatile unsigned char *dest_c      = dest;

    while (n > 0) {
        n--;
        dest_c[n] = src_c[n];
    }
    return  dest;
}

编写自己的memcpy_v() 的一个唯一原因是编译器可以“理解”/分析memcpy() 并发出与预期截然不同的代码——甚至优化它，如果编译器认为副本不是需要。提醒自己编译器认为memcpy() 操作的内存是非易失性的。

---

然而 OP 错误地使用了volatile struct Eusart eusart;。访问eusart 需要volatile 不提供的保护。

在 OP 的情况下，代码可以将volatile 放在缓冲区上，然后使用memcpy() 就好了。

剩下的问题在于 OP 如何使用eusart 的代码很少。使用 volatile 并不能解决 OP 的问题。 OP 确实断言“我以原子方式写入它”，但没有发布 atomic 代码，这是不确定的。

---

eusart.tx.msg_len 成为volatile 的代码如下所示，但这还不够。 volatile 确保 .tx.msg_len 不会被缓存，而是每次都重新读取。

while (eusart.tx.msg_len)
    ;

但.tx.msg_len 的读取并未指定为原子。当.tx.msg_len == 256 和 ISR 触发时，递减 .tx.msg_len，读取 LSbyte（256 中的 0）和 MSbyte（255 中的 0），非 ISR 代码可能会将 .tx.msg_len 视为 0，而不是 255 或 256 ，从而在错误的时间结束循环。 .tx.msg_len 的访问需要指定为不可分割（原子），否则，偶尔代码会神秘地失败。

while (eusart.tx.msg_len); 也存在无限循环。如果传输因某种原因而不是空的而停止，则 while 循环永远不会退出。

建议在检查或更改eusart.tx.msg_len, eusart.tx.msg_posn 时阻止中断。查看您的编译器对 atomic 或

的支持

size_t tx_msg_len(void) {
  // pseudo-code
  interrupt_enable_state = get_state();
  disable_interrupts();
  size_t len = eusart.tx.msg_len;
  restore_state(interrupt_enable_state);
  return len;
}

---

一般通信代码思路：

1. 当非 ISR 代码读取或写入 eusart 时，请确保 ISR永远无法更改 eusart。

2. 不要在第 1 步中长时间阻止 ISR。

3. 不要假设底层ISR() 将成功链接输入/输出而不会出现问题。顶级代码应准备好在停止时重新启动输出。

Answer 2

该标准缺乏任何方法，程序员可以要求通过普通指针访问存储区域的操作在执行特定的volatile 指针访问之前完成，并且也缺乏任何方法来确保操作直到执行了某些特定的volatile 指针访问之后，才执行通过普通指针访问存储区域的操作。由于volatile 操作的语义是实现定义的，标准的作者可能期望编译器编写者能够识别他们的客户何时可能需要这种语义，并以符合这些需求的方式指定他们的行为。不幸的是，这并没有发生。

实现您需要的语义要么使用“流行扩展”，例如 clang 的 -fms-volatile 模式，一种编译器特定的内在函数，要么将 memcpy 替换为效率极低的东西任何假设的优势编译器都可以通过不支持这种语义获得。