Threading implications of AsynchronousByteChannel

Question

The Javadoc for AsynchronousByteChannel.read() says the operation takes place asynchronously, but what happens when the end of stream has been reached? Is an implementation allowed to fire the completion handler within the same thread that invoked read()? From the implementation's point of view, there is no reason to carry out this operation asynchronously, because we already know the result. Similarly, if a user attempts to read into a ByteBuffer where remaining() returns 0 we know the read operation must return 0.

I ask because I've run into a race condition in my own AsynchronousByteChannel implementation. I'm invoking a completion handler that invokes notify() on itself when the operation completes. I then invoke the following user code:

CompletionHandler<?, ?> handler = ...;
synchronized (handler)
{
  asyncByteChannel.read(handler);
  handler.wait();
}

Note the user is assuming that the handler will be notified when the operation completes, but because read() actually invokes the completion-handler synchronously it gets notified before wait() and the latter will block forever.

Does the specification require me to update CompletionHandler in a separate thread or should users be aware of the fact that the thread that invokes read() may carry out some operations synchronously?

Its threading model is a mess. The javadoc on async group is unparsable. Threading should be left to developers - that's the easy part. Unfortunately they decided to help us on that. The result is very complicated, unintuitive, ill-documented(because they can't explain the mess). A casual reviewer might find the API alright - indeed why should it be hard? But when one seriously build an app on top of it, the complexities will drive him nuts. — irreputable, Jul 13 '11 at 02:01

score 1 · Answer 1 · answered Jul 12 '11 at 15:34

1

Even when the handler is invoked on another thread, there is no guarantee it will be invoked after the read method returns, i.e. after your wait() started. (Okay, the synchronization lock seems to guarantee this.)

You should use synchronization and a boolean variable for the waiting and locking:

CompletionHandler<?, ?> handler = ...;
synchronized (handler)
{
   asyncByteChannel.read(handler);
   while(!handler.finished) {
     handler.wait();
   }
}

... and your handler will then set the finished variable to true.

answered Jul 12 '11 at 15:34

Paŭlo Ebermann

73,284
20
146
210

Your proposed solution is great **if** I'm allowed to process the CompletionHandler on the main thread. It's still not clear whether this is the case :) – Gili Jul 12 '11 at 15:40
No, the solution is usable always. (It is not necessary if it is not allowed - but you should wait in a loop anyways, as there may be spurious wakeups.) – Paŭlo Ebermann Jul 12 '11 at 16:56
I agree, but that's not what this question is about. It's about whether the specification allows notifying on the same thread. – Gili Jul 12 '11 at 17:01

Gili · Accepted Answer · 2011-07-12T17:04:36.463

Looking at http://www.docjar.com/html/api/sun/nio/ch/AsynchronousSocketChannelImpl.java.html they always update CompletionHandler in a separate thread, but Future is updated in the same thread. Search for variable hasSpaceToRead to find the method in question.

I'm guessing their line of reasoning goes something like this:

We create the Future returned to the user so there is no way he's interacting with it (synchronizing, etc.) before we return the object.
The user creates the CompletionHandler, so we have no way of controlling what the implementation does (for all we know, we could trigger a deadlock!). Don't take a chance, fire the completion handler in a separate thread.

UPDATE: I stand corrected. According to Invoker.invoke() "If the current thread is in the channel group's thread pool then the handler is invoked directly, otherwise it is invoked indirectly."

SOLVED: According to http://download.oracle.com/javase/7/docs/api/java/nio/channels/AsynchronousChannelGroup.html "Where an I/O operation completes immediately, and the initiating thread is one of the pooled threads in the group then the completion handler may be invoked directly by the initiating thread."

Threading implications of AsynchronousByteChannel

2 Answers2

Linked