Name: mc57594 Date: 11/15/99
may be related to :
1239258 java.io.Piped*Stream: Connect method unsafe
4221634 PipedInputStream blocks on read (even if data available)
-----------------------------------
There is a race condition in java.io.PipedOutputStream.connect (PipedInputStream snk).
This method does not acquire the lock on "snk" before re-setting "snk.in" to minus 1. This can cause other methods of PipedInputStream, for example PipedInputStream.receive(), to behave in an erroneous manner.
An example of how this could happen is as follows: A PipedInputStream object is created, called say x, and so is a PipedOutputStream object, called say y. Then "x.receive(int b)" is called in one thread. The body of the receive method is executed, up until just before the assignment:
buffer[in++] = ...
At this stage, the field "x.in" must be greater than or equal to 0, because of the preceding if test. However, a second thread could now call "y.connect(x)", which would have the effect of re-setting "x.in" to minus 1. The first thread then attempts to perform the assignment,
buffer[in++] = ...
and, since "in" is now negative, this would cause an exception to be thrown from PipedInputStream.receive(). Although the exception is thrown from PipedInputStream.receive(), the underlying cause of the problem is a race condition in PipedOutputStream.connect (PipedInputStream snk).
(Review ID: 96873)
======================================================================
may be related to :
1239258 java.io.Piped*Stream: Connect method unsafe
4221634 PipedInputStream blocks on read (even if data available)
-----------------------------------
There is a race condition in java.io.PipedOutputStream.connect (PipedInputStream snk).
This method does not acquire the lock on "snk" before re-setting "snk.in" to minus 1. This can cause other methods of PipedInputStream, for example PipedInputStream.receive(), to behave in an erroneous manner.
An example of how this could happen is as follows: A PipedInputStream object is created, called say x, and so is a PipedOutputStream object, called say y. Then "x.receive(int b)" is called in one thread. The body of the receive method is executed, up until just before the assignment:
buffer[in++] = ...
At this stage, the field "x.in" must be greater than or equal to 0, because of the preceding if test. However, a second thread could now call "y.connect(x)", which would have the effect of re-setting "x.in" to minus 1. The first thread then attempts to perform the assignment,
buffer[in++] = ...
and, since "in" is now negative, this would cause an exception to be thrown from PipedInputStream.receive(). Although the exception is thrown from PipedInputStream.receive(), the underlying cause of the problem is a race condition in PipedOutputStream.connect (PipedInputStream snk).
(Review ID: 96873)
======================================================================
- relates to
-
JDK-8266857 PipedOutputStream.sink should be volatile
- Resolved