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 Fri, 16 Oct 2009 03:12:31 GMT

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

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

Thanks Jesse, fix applied at r825746, please verify.

About "maintaining indices", I can understand the memory is limited on embedded system and
to be selected channel set usually is small,  so the overhead of iteration is not outstanding,
it's better iteration than indeces. But on server, the memory for indeices is *really* not
a big deal, and for high throughput server, the number of selected channel can be very large,
it's not acceptable to iterate them all every select. 

The two ways fit different requirements and cases, it's best if we can find a common way that
can be accepted by both embedded and server environments.

> 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