I don’t believe pipe(2) is safe for lock-free multiple-producer/multiple-consumer use in most implementations. It can be safe in the multiple writers case; POSIX guarantees atomic writes as long as all writes to the pipe are less than PIPE_BUF size. But I don’t believe POSIX provides useful guarantees about what happens when multiple processes simultaneously read from the same pipe without locking.
The only sensible behavior would be for small size reads to be atomic too. You can be assured you’ll read contiguous bytes at least. It would be extra work for the kernel to split things up.
Generally threaded behavior with system calls seems unspecified, but works as you’d want. If three threads call accept(), only one of them gets a connection, etc.
That said, Linux has some nonstandard relaxations, afaik. Multiple writes (from threads, or processes) to append a regular file sometimes fail to advance the file position, resulting in overwriting (lost data). (Citation needed.)
Good point; it’d be interesting to test whether in practice pipe(2) can be used for this purpose on most Unixes, even without POSIX guaranteeing the right semantics. The other main difference then would be the performance assumptions; this implementation looks designed to have hundreds or thousands of simultaneous readers/writers, which pipe(2) is probably not optimized for (but I’d have to test to say for sure).
I am most likely misunderstanding something here, but is it not the same as the
pipe(2)system call?Pipe is an unfortunate name for something that looks more like a queue.
I don’t believe
pipe(2)is safe for lock-free multiple-producer/multiple-consumer use in most implementations. It can be safe in the multiple writers case; POSIX guarantees atomic writes as long as all writes to the pipe are less than PIPE_BUF size. But I don’t believe POSIX provides useful guarantees about what happens when multiple processes simultaneously read from the same pipe without locking.The only sensible behavior would be for small size reads to be atomic too. You can be assured you’ll read contiguous bytes at least. It would be extra work for the kernel to split things up.
Generally threaded behavior with system calls seems unspecified, but works as you’d want. If three threads call accept(), only one of them gets a connection, etc.
That said, Linux has some nonstandard relaxations, afaik. Multiple writes (from threads, or processes) to append a regular file sometimes fail to advance the file position, resulting in overwriting (lost data). (Citation needed.)
Good point; it’d be interesting to test whether in practice
pipe(2)can be used for this purpose on most Unixes, even without POSIX guaranteeing the right semantics. The other main difference then would be the performance assumptions; this implementation looks designed to have hundreds or thousands of simultaneous readers/writers, whichpipe(2)is probably not optimized for (but I’d have to test to say for sure).I see, thank for the explanation