多线程:读取/写入管道 [英] Multithreading: Read from / write to a pipe

问题描述

我将一些数据写入管道-可能是大量数据，而且间隔是随机的.如何从管道读取数据?

可以吗?

• 在主线程(当前进程)中再创建两个线程(2、3)
• 第二个线程有时会写入管道(并冲洗管道吗?)
• 第3个线程具有无限循环，该循环读取管道(然后休眠一段时间)

这到目前为止是正确的吗?

现在，有几件事我不明白:

• 我是否必须在写操作时锁定(互斥体?)管道?
• IIRC，当写入管道并且其缓冲区已满时，写入端将阻塞，直到我读取已写入的数据，对吗?如何检查管道中的读取数据，不是太频繁，也不是太少?这样第二个线程就不会阻塞?管道是否有select之类的东西?
• 可以将管道设置为更多无缓冲的，或者我必须定期冲洗它-哪个更好?
• 是否应该再创建一个线程，仅用于在写入后刷新管道?因为刷新也会阻塞，所以当缓冲区已满时，对吗?我只是不希望第一线程和第二线程阻塞....

抱歉，我认为这个问题与平台无关，但以防万一:我是从Win32的角度来看这个问题的，可能是MinGW C ...

解决方案

我在这里没有回答您的所有问题，因为有很多问题，但是在回答:

我是否必须在写入时锁定(互斥体?)管道?

这个问题的答案是特定于平台的，但是在大多数情况下，我会猜测为是.

这取决于管道上的写/读操作是否是原子的.如果 read 或 write 操作不是原子的(很可能是写操作)，那么您将需要在写入和读取时锁定管道，以防止出现竞争情况.

例如，假设对管道的写入可在机器代码中编译为2条指令:

INSTRUCTION 1
INSTRUCTION 2

假设您在这2条指令之间进行了线程上下文切换，并且您的 reading 线程尝试读取处于中间状态的管道.这可能会导致崩溃或(更糟糕的)数据损坏，这通常会在代码中其他地方的崩溃中表现出来.这通常是由于种族条件而导致的，这种不确定性通常是不确定的，难以诊断或再现.

通常，除非您可以保证所有线程都将使用原子指令集访问共享资源，否则必须使用互斥锁或关键部分.

I write some data to a pipe - possibly lots of data and at random intervals. How to read the data from the pipe?

Is this ok:

• in the main thread (current process) create two more threads (2, 3)
• the second thread writes sometimes to the pipe (and flush-es the pipe?)
• the 3rd thread has infinite loop which reads the pipe (and then sleeps for some time)

Is this so far correct?

Now, there are a few thing I don't understand:

• do I have to lock (mutex?) the pipe on write?
• IIRC, when writing to pipe and its buffer gets full, the write end will block until I read the already written data, right? How to check for read data in the pipe, not too often, not too rarely? So that the second thread wont block? Is there something like select for pipes?
• It is possible to set the pipe to unbuffered more or I have to flush it regularly - which one is better?
• Should I create one more thread, just for flushing the pipe after write? Because flush blocks as well, when the buffer is full, right? I just don't want the 1st and 2nd thread to block....

[Edit] Sorry, I thought the question is platform agnostic but just in case: I'm looking at this from Win32 perspective, possibly MinGW C...

解决方案

I'm not answering all of your questions here because there's a lot of them, but in answer to:

do I have to lock (mutex?) the pipe on write?

The answer to this question is platform specific, but in most cases I would guess yes.

It comes down to whether the write/read operations on the pipe are atomic. If either the read or write operation is non-atomic (most likely the write) then you will need to lock the pipe on writing and reading to prevent race conditions.

For example, lets say a write to the pipe compiles down to 2 instructions in machine code:

INSTRUCTION 1
INSTRUCTION 2

Let's say you get a thread context switch between these 2 instructions and your reading thread attempts to read the pipe which is in an intermediate state. This could result in a crash, or (worse) data corruption which can often manifest itself in a crash somewhere else in the code. This will often occur as a result of a race condition which are often non-deterministic and difficult to diagnose or reproduce.

In general, unless you can guarantee that all threads will be accessing the shared resource using an atomic instruction set, you must use mutexes or critical sections.

这篇关于多线程:读取/写入管道的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！