Question about threading implications of specification

[Gili]

Gili wrote:
> 
> Hi,
> 
> The specification for AsynchronousByteChannel.read() talks about the
> operation taking place asynchronously, but what happens when the end of
> stream has been reached? Is an implementation allowed to fire the
> completion handler (or set the future) within the 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. A similar case occurs if a user attempts to read into a buffer
> where remaining() returns 0 (so we know the read operation must return 0).
> 
> I ask because I've run into a race condition in my implementation. I'm
> invoking a completion handler that invokes notify() on itself when the
> operation completes. I then invoke the following user code:
> 
> synchronize (handler)
> {
>   foo.read(handler);
>   handler.wait();
> }
> 
> Note the user is assuming that the handler will be notified when the
> operation completes, but because read() runs synchronously at end of
> stream the handler gets notified before wait() and the latter will block
> forever.
> 
> Does the specification require me to update Future/CompletionHandler in a
> separate thread or should users be aware of the fact that the thread that
> invokes read() may update said objects itself?
> 
> Thank you,
> Gili
> 


FYI, I posted this question to
http://stackoverflow.com/questions/6666659/threading-implications-of-asynchronousbytechannel/6667926

Gili

--
View this message in context: http://nio-discuss.970641.n3.nabble.com/Question-about-threading-implications-of-specification-tp3162701p3163079.html
Sent from the nio-discuss mailing list archive at Nabble.com.