Fwd: Re: Question about threading implications of specification

[Gili]

Hi Sebastian,

    If handler.completed() is invoked in the same thread as foo.read() then
handler.notify() gets invoked before handler.wait(). Remember we're holding
a reentrant lock before invoking read() so nothing stops handler.completed()
from getting invoked.

Gili


Sebastian Sickelmann wrote:
> 
> Hi,
> 
> i am not quite sure what the specification says. But the sync on handler
> and the notify on handler inside foo.read() ensures that it is invoked
> in the right and expected order. Because the notify on handler must be
> inside 
> a sync on handler or an synchronized method.
> 
> Kind regards
> Sebastian
> -------- Original-Nachricht --------
>> Datum: Tue, 12 Jul 2011 08:00:45 -0700 (PDT)
>> Von: Gili <cowwoc at bbs.darktech.org>
>> An: nio-discuss at openjdk.java.net
>> Betreff: Question about threading implications of specification
> 
>> 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
>> 
>> --
>> View this message in context:
>> http://nio-discuss.970641.n3.nabble.com/Question-about-threading-implications-of-specification-tp3162701p3162701.html
>> Sent from the nio-discuss mailing list archive at Nabble.com.
> 
> -- 
> Empfehlen Sie GMX DSL Ihren Freunden und Bekannten und wir
> belohnen Sie mit bis zu 50,- Euro! https://freundschaftswerbung.gmx.de
> 


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