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 Thu, 27 Aug 2009 02:56:59 GMT

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

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

I noticed there is time window between doCancel() and prepareChannels() in selectInternal,
if other thread cancel keys to be selected in this window, may cause CancelledKeyException
when calling key.interestOps() in prepareChannels(). That may also happen in processSelectResult.


Maybe we can add a method to SelectionKey which get interestOps but doesn't check  validation,
because there is no harm to select cancelled keys.  From spec:
"If any keys were added to the cancelled-key set while step (2) was in progress then they
are processed as in step (1). "
so we must make sure returned selected key set doesn't contain cancelled key. I'll try to
make a patch for this.

> 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: Mark Hindess
>         Attachments: NIO_Concurrency_issues.patch
>
>   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