Messages in this thread | | | Date | Wed, 12 Jul 2000 23:46:32 +0200 | From | Christian Ehrhardt <> | Subject | Possible race in pipe code |
| |
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/
| |