JDK-8054039 Deadlock during interrupting FileChannel

[Frank Yuan]

Hi Frank,

 

On Sep 9, 2015, at 12:59 AM, Frank Yuan <frank.yuan at oracle.com <mailto:frank.yuan at oracle.com> > wrote:





Thank you for review and your comments:)

 

You are welcome.





The size of my last mail is too large, is still held by maillist moderator, I have to send some content again(the diagram still
can't be attached.).

 

You could upload the diagram and a webrev to cr.openjdk.java.net <http://cr.openjdk.java.net>  assuming you have an ID. If not, I
could do it for you.





I have uploaded the diagram to the bug https://bugs.openjdk.java.net/browse/JDK-8054039, hope more people can review it.

 

 

I am suspicious of the use of reflection here.

I also have some concern for this solution, because in this fix nio will depend on the private method of Thread -- interrupt0, it
will break the encapsulation. However it's an available solution in theory.

 

True but I think the second one is better.





Within the scope of AbstractInterruptibleChannel I do not see any problem with the change that you propose. Given that the affected
instance variables are private to the class and that AtomicBoolean "generally" follows the rules for volatiles it looks conceptually
valid. I do not know however about the implications with respect to interactions with other classes. For example, could this change
provoke some unforeseen behavior as a result of subtle changes in timing?

 

As my understood, this solution won't spend more time on begin() than the old code, compareAndSet is atomic and there is no loop or
wait. Anyway I am not sure your concern, will do more tests, hope more people can review it.

 

Indeed I don't know whether there would be any effect: it was simply an observation. I expect others will comment when they have
time.

 

Brian

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/nio-dev/attachments/20150910/063cfae7/attachment.html>