harmony-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Jesse Wilson (JIRA)" <j...@apache.org>
Subject [jira] Commented: (HARMONY-6312) Concurrency problems in NIO
Date Sat, 26 Sep 2009 01:09:16 GMT

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

Jesse Wilson commented on HARMONY-6312:
---------------------------------------

Regis,

I examined your patches:
  The change to OSNetworkSystemLinux doesn't appear to honor the timeout properly, but I'm
not familiar with this API.
  The fix to OSNetworkSystem.java is fantastic, although I don't see reason to keep the previous
select() method. 
  The other changes continue to rely on indexing FDs. This brings no measurable performance
improvement so I don't think it pulls its weight.

I'm currently testing a patch that builds upon your improvements to OSNetworkSystem. The forthcoming
patch continues to use the strategy of iterating through all keys in the key set for each
select(); I have measured that this has no negative impact on performance.

Aside: I found processing a .zip of git patches quite cumbersome to work with.

> 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, 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