Name: dk106046 Date: 05/14/2003
The read/write values in a selector can get out of sync with the underlying read/write values
used to poll the channel.
------------
A client/server application which creates many threads, each of which is available to process a read or
write from the same channel. Each time a selector is finished with by a thread it is disposed (after
100 uses by default). During reading from a channel, the read/write interest on the selector is changed
so that read interest is removed whilst reading, and restored after reading.
As deregistration (implDereg) alters the order of the unerlying list of file interests by copying the
last record to the one to be deregistered, then removing the last record, it is possible that the
deregsitration is in process whilst the last record is being updated by a read operation, such that
the modification of the read interest (either adding or removing it) gets lost.
It is not sufficient to synchronize on the selector being de-registered, you also have to synchronize
on the last one in the list to safely deregister.
There is no minimal set of code which reproduces this, it requires the full client/server Nio test
from the SVT suite.
======================================================================
--
The read/write values in a selector can get out of sync with the underlying read/write values
used to poll the channel.
------------
A client/server application which creates many threads, each of which is available to process a read or
write from the same channel. Each time a selector is finished with by a thread it is disposed (after
100 uses by default). During reading from a channel, the read/write interest on the selector is changed
so that read interest is removed whilst reading, and restored after reading.
As deregistration (implDereg) alters the order of the unerlying list of file interests by copying the
last record to the one to be deregistered, then removing the last record, it is possible that the
deregsitration is in process whilst the last record is being updated by a read operation, such that
the modification of the read interest (either adding or removing it) gets lost.
It is not sufficient to synchronize on the selector being de-registered, you also have to synchronize
on the last one in the list to safely deregister.
There is no minimal set of code which reproduces this, it requires the full client/server Nio test
from the SVT suite.
======================================================================
--
- duplicates
-
JDK-6429204 (se) Concurrent Selector.register and SelectionKey.interestOps can ignore interestOps
- Closed