lkml.org 
[lkml]   [2000]   [Jul]   [12]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectPossible 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/

\
 
 \ /
  Last update: 2005-03-22 13:57    [W:0.039 / U:0.540 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site