5

我一直在努力搜索（在 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 并不完全相同，但我的观点是，仔细确定并没有什么坏处。我能想到的就是继续发送数据并寻找一个排列——我希望有一些更科学的东西，理想情况下，是确定性的。不幸的是，我完全不记得以前大学时代的并发编程课程。我会非常感激在正确方向上的一记耳光或推搡。如果您选择回复，请提前感谢您。

亲切的问候，

杰斯


驱动程序/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;
}


拱/臂/包括/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);
}


驱动程序/串行/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} 或更少字节的写入应该是原子的。
4

2 回答 2

3

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

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

简而言之，我建议不要尝试验证“从此设备读取/写入实际上是原子操作”。如果更高版本的 linux（或完全不同的 o/s）未能按照您需要的方式实现原子性，则很难有信心去做，并且会给您留下一个可能会出现细微故障的应用程序。

于 2009-12-28T19:06:08.003 回答
2

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

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

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

于 2009-12-28T19:06:47.890 回答