NIO.2 and GC activity

[Leon Finker]

That's the whole issue: the order of multiple simultaneous read completions
on the same socket or file *are not guaranteed* when it ends up in the user
code. Even in MSDN for WSARecv they say that order is not guaranteed in this
case. But they also do not prevent/forbid programmers from doing this. They
even recommend this in Microsoft books (i.e.: Concurrent Programming on
Windows, and I can't remember all the other references where I learned
this). The order can be re-sequenced by programmer on read completions by
first associating a sequence number with scheduled reads. This has been done
for high throughput servers. I don't know if public source reference exists
or not.

Having multiple outstanding requests on socket/file can increase
utilization, leading to overall speedup. For example, multiple outstanding
disk I/Os can allow the I/O subsystem to optimize the movement of the hard
disk arm to reduce seek time (adjacent reads can be merged by file manager,
reads can be sorted by location on disk, etc).  In sockets case, it can
allow to skip extra buffering in driver/winsock2 and write directly to user
supplied buffer as data is ready thus reducing delays for real-time servers
(market data).

-----Original Message-----
From: nio-dev-bounces at openjdk.java.net
[mailto:nio-dev-bounces at openjdk.java.net] On Behalf Of Salter, Thomas A
Sent: Friday, April 17, 2009 10:08 AM
To: nio-dev at openjdk.java.net
Subject: RE: NIO.2 and GC activity

I couldn't find any MSDN reference that guarantees the order in which
multiple pending receives would complete.  Do they promise to satisfy
requests in the order they are issued?  Do they guarantee to post completion
status in the order the data is received?  I would certainly want to see
this spelled out in Windows documentation before writing an application that
depended on a particular order.  The cited MSDN Magazine article is 9 years
and 2 OS releases old and it only makes a passing reference to multiple
pending receives with no guidance on how to order the data.



-----Original Message-----
From: nio-dev-bounces at openjdk.java.net
[mailto:nio-dev-bounces at openjdk.java.net] On Behalf Of Alan Bateman
Sent: Friday, April 17, 2009 4:05 AM
To: Leon Finker
Cc: nio-dev at openjdk.java.net
Subject: Re: NIO.2 and GC activity

Leon Finker wrote:
> I agree there is no advantage for the writes, and I don't advocate it.
> On the reads I disagree that the order can't be guaranteed or
> re-sequenced on completion/failure. One is always able to re-establish
> the original order of reads that were scheduled on their completion or
> failure simply by associating the counter with the scheduled reads and
> then re-establishing the sequence. Yes, one has to be aware that if
> they schedule a read on non I/O windows pool thread and thread
> immediately exits, the I/O request will be canceled. But this applies
> to current NIO.2 implementation even with non simultaneous reads.
Our implementation never initiates I/O operations on non-pooled threads.
Instead, if a non-pooled thread invokes read/write it will be queued (via a
message posted to the completion port) so that it is initiated on a pooled
thread. That is where the ordering becomes undefined. Another case is where
a pool thread associated with one group initiates an I/O operation on a
channel associated with a different group.

> I agree the code is somewhat involved, and one has to deal with
> concurrency, but it's an option for core communication framework
> libraries out there. This optimization is not for every case, it's for
> specific communication/protocol patterns. So, I'm not sure if
> comparison will be fair. It's just a suggestion based on experience.
> If there is no need for this from the community, then you're right it can
be added later.
>
Yes, this is something for later once people have more experience using the
API.

-Alan.