Hi,
look at the following scenario. We work with a single pipe that is
initially empty:
Thread 1 Thread 2 Thread 3 Comments
write 3000 bytes This will go through
to a pipe
write 3000 bytes This write will block
to the pipe
blocked in pipe_wait Try to read 4000 Try to read Both reads must happen
bytes from the pipe. 10 bytes. at almost the same
time we assume Thread
2 is selected first.
blocked in pipe_wait Reads 3k bytes Waiting for We have a waiting
PIPE_SEM. writer, i.e. Thread2
won't return.
Releases PIPE_SEM We assume Thread 1
and wakes up is selected (doesn't
PIPE_WAIT. really matter).
write 3000 bytes to waits on PIPE_WAIT Still waiting
the pipe (now empty).
Wake up PIPE_WAIT and tries to get tries to get We assume Thread 3
release PIPE_SEM. PIPE_SEM PIPE_SEM gets PIPE_SEM.
terminates still waiting reads 10 bytes
and returns
reads additional
1000 bytes
Now let's see what we got:
Thread 3 reads the first 10 bytes of the second write.
Thread 2 reads 4000 bytes: 3000 bytes from the first write and bytes 11
through 1010 from the second write, i.e. this thread reads 4000 non
continuous bytes in a single read system call.
This is definitely a bad thing and probably violates standards.
I see three possible solutions:
* I missed something
* Don't wait for writers once we read at least one byte (this is how
2.2 did it).
* Add a semaphore to each pipe that allows only one thread per pipe in
the pipe_read path.
If someone confirms that the problem exits and noone else is faster
I'll submit a patch that implements the thrid solution.
regards Christian
-- THAT'S ALL FOLKS!- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.rutgers.edu Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Sat Jul 15 2000 - 21:00:15 EST