如何验证原子写入？

Question

我努力搜索（在 S[O|F|U] 网络和其他地方）并相信这是一个不常见的问题。我正在使用运行 Debian Linux 2.6.28-4 的 Atmel AT91SAM9263-EK 开发板（ARM926EJ-S 内核，ARMv5 指令集）。我正在使用（我相信）tty 驱动程序与 RS-485 串行控制器进行通信。我需要确保写入和读取是原子的。几行源代码（在本文末尾列出的相对于内核源安装目录的代码）暗示或隐含地说明了这一点。

有什么方法可以验证向/从该设备写入/读取实际上是原子操作吗？或者， /dev/ttyXX 设备是否被视为 FIFO 并且争论就此结束？仅仅相信代码正在执行它所做的这一声明似乎还不够 - 就在今年 2 月，freebsd 还被证明缺乏小行的原子写入。是的，我意识到 freebsd 与 Linux 并不完全相同，但我的观点是，仔细确定并没有什么坏处。我能想到的就是继续发送数据并寻找排列 - 我希望得到一些更科学的东西，并且理想情况下是确定性的。不幸的是，我对以前大学时代的并发编程课程一无所知。我非常感谢朝正确方向的一巴掌或一推。如果您选择回复，请提前致谢。

亲切的问候，

杰斯

drivers/char/tty_io.c:1087

void tty_write_message(struct tty_struct *tty, char *msg)
{
    lock_kernel();
    if (tty) {
        mutex_lock(&tty->atomic_write_lock);
        if (tty->ops->write && !test_bit(TTY_CLOSING, &tty->flags))
            tty->ops->write(tty, msg, strlen(msg));
        tty_write_unlock(tty);
    }
    unlock_kernel();
    return;
}

arch/arm/include/asm/bitops.h:37

static inline void ____atomic_set_bit(unsigned int bit, volatile unsigned long *p)
{
    unsigned long flags;
    unsigned long mask = 1UL << (bit & 31);

    p += bit >> 5;

    raw_local_irq_save(flags);
    *p |= mask;
    raw_local_irq_restore(flags);
}

drivers/serial/serial_core.c:2376

static int
uart_write(struct tty_struct *tty, const unsigned char *buf, int count)
{
    struct uart_state *state = tty->driver_data;
    struct uart_port *port;
    struct circ_buf *circ;
    unsigned long flags;
    int c, ret = 0;

    /*
     * This means you called this function _after_ the port was
     * closed.  No cookie for you.
     */
    if (!state || !state->info) {
        WARN_ON(1);
        return -EL3HLT;
    }

    port = state->port;
    circ = &state->info->xmit;

    if (!circ->buf)
        return 0;

    spin_lock_irqsave(&port->lock, flags);
    while (1) {
        c = CIRC_SPACE_TO_END(circ->head, circ->tail, UART_XMIT_SIZE);
        if (count < c)
            c = count;
        if (c <= 0)
            break;
        memcpy(circ->buf + circ->head, buf, c);
        circ->head = (circ->head + c) & (UART_XMIT_SIZE - 1);
        buf += c;
        count -= c;
        ret += c;
    }
    spin_unlock_irqrestore(&port->lock, flags);

    uart_start(tty);
    return ret;
}

另外，来自 man write(3) 文档：

尝试写入管道或 FIFO 有几个主要特征：

• 原子/非原子：如果一次操作中写入的总量不与任何其他进程的数据交错，则写入是原子的。当有多个写入器向单个读取器发送数据时，这非常有用。应用程序需要知道可以原子执行多大的写入请求。该最大值称为 {PIPE_BUF}。 IEEE Std 1003.1-2001 的这一卷并没有规定超过 {PIPE_BUF} 字节的写入请求是否是原子的，而是要求 {PIPE_BUF} 或更少字节的写入应该是原子的。

Answer 1

我认为，从技术上讲，设备不是 FIFO，因此根本不清楚您引用的保证是否适用。

您是否担心进程内的部分写入和读取，或者您实际上是否从不同进程读取和/或写入同一设备？假设是后者，您最好实现某种代理进程。代理独占该设备并执行所有读取和写入，从而完全避免了多进程原子性问题。

简而言之，我建议不要尝试验证“从此设备读取/写入实际上是原子操作”。如果较新版本的 linux（或完全不同的操作系统）无法按照您需要的方式实现原子性，那么这将很难充满信心地完成，并且您的应用程序可能会出现微妙的故障。

Answer 2

我认为 PIPE_BUF 是正确的。现在，少于 PIPE_BUF 字节的写入可能不是原子的，但如果不是，那就是操作系统错误。我想你可以在这里询问操作系统是否有已知的错误。但实际上，如果它有这样的错误，就应该立即修复。

如果您想以原子方式写入超过 PIPE_BUF 的内容，我认为您不走运。我认为除了应用程序协调和合作之外，没有任何方法可以确保更大尺寸的写入以原子方式发生。

解决此问题的一种方法是将您自己的进程放在设备前面，并确保每个想要写入设备的人都联系该进程并向其发送数据。然后，您可以在原子性保证方面做任何对您的应用程序有意义的事情。