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

问题描述 投票:9回答:2

我有一个用于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缓冲区时)可以知道该怎么做。


编辑(相关)(Jul / 19):

volatile vs memory barrier for interrupts

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

c casting interrupt volatile memcpy
2个回答
4
投票

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(0从256)和MSbyte(0从255)时,非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()会在没有打嗝的情况下成功地链接输入/输出。顶级代码应该准备好在它停止时重新启动输出。

0
投票

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

实现你需要的语义将要么使用“流行的扩展”,例如clang的-fms-volatile模式,特定于编译器的内在,或者用一些非常低效的东西取代memcpy,以至于淹没编译器可能获得的所有优势不支持这种语义。

© www.soinside.com 2019 - 2024. All rights reserved.