harmony-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Regis Xu (JIRA)" <j...@apache.org>
Subject [jira] Commented: (HARMONY-6312) Concurrency problems in NIO
Date Tue, 13 Oct 2009 07:09:31 GMT

    [ https://issues.apache.org/jira/browse/HARMONY-6312?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12764981#action_12764981
] 

Regis Xu commented on HARMONY-6312:
-----------------------------------

I have committed part of the patch NIO_Concurrency_issues_2.patch at r824614, included:
 - Permit extra space in the arrays sent to INetworkSystem
 - Move Javadoc from INetworkSystem implementation to interface
 - Reuse arrays rather than reallocating them for both input and output of INetworkSystem
 - Add tests for keySet viewing modifications and keys cancelled during select 

"Remove indices" is still in discussion, need more tests and investigation.

I also add a timeout for select() in test case test_cancelledKeys, because there is time window
main thread waked up and checked "!complete.get()" first, and then "complete" is set to "true",
that will cause test case block forever.

Jesse, please verify if that was applied as you expected.

> Concurrency problems in NIO
> ---------------------------
>
>                 Key: HARMONY-6312
>                 URL: https://issues.apache.org/jira/browse/HARMONY-6312
>             Project: Harmony
>          Issue Type: Bug
>          Components: Classlib
>         Environment: SVN Revision: 801399
>            Reporter: Jesse Wilson
>            Assignee: Regis Xu
>         Attachments: cancelledkey.diff, harmony_svn.html, harmony_svn_plus_patch_2009-08-19.html,
NIO_Concurrency_issues.patch, NIO_Concurrency_issues_2.patch, ri.html, selector.zip, SelectorBenchmark.java
>
>   Original Estimate: 72h
>  Remaining Estimate: 72h
>
> There's several potential concurrency problems in our NIO implementation...
>  - Charset#isSupported isn't synchronized, but it accesses mutable member cachedCharsetTable.
>  - In SelectionKeyImpl, stHash++ is a non-atomic operation so multiple SelectionKey instances
may receive the same hash code. (Why not use the default hash code?)
>  - In SelectorImpl, the unmodifiableKeys member is never synchronized on. But the documentation
specifies that clients can synchronize on that set to guard against changes
> These are the obvious problems; I suspect there are more subtle concurrency defects at
play here. I'll prepare a patch to address the major issues, and we should consider a rigorous
approach (Findbugs?) to discover concurrency problems.
> #Android

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


Mime
View raw message