[jira] Updated: (RIVER-101) (mux) refactor SelectionManager's concurrency design

["Thomas Vinod Johnson (JIRA)" <ji...@apache.org>]

     [ https://issues.apache.org/jira/browse/RIVER-101?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Thomas Vinod Johnson updated RIVER-101:
---------------------------------------

    Component/s: net_jini_jeri

Add component

> (mux) refactor SelectionManager's concurrency design
> ----------------------------------------------------
>
>                 Key: RIVER-101
>                 URL: https://issues.apache.org/jira/browse/RIVER-101
>             Project: River
>          Issue Type: Improvement
>          Components: net_jini_jeri
>    Affects Versions: jtsk_2.0
>            Reporter: Thomas Vinod Johnson
>            Priority: Minor
>
> The implementation class com.sun.jini.jeri.internal.runtime.SelectionManager, which is used to manage non-blocking I/O operations for net.jini.jeri.connection-based endpoints in NIO mode, is currently coded to support running multiple "select threads" to allow for increased concurrency of performing ready I/O operations on multiprocessor machines, although the number of select threads is actually hard-coded to one (greater numbers have not shown to be beneficial in practice...).  The approach taken for this general support of multiple select threads is suboptimal and likely rather detrimental to performance even when only one select thread is used.
> In the current approach, one selector is shared by all N select threads-- only one thread may actually be blocking on a select operation at a time 
>  Bugtraq ID [6305650|http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6305650
> (Selector.select is synchronized), but the idea is that once that threads unblocks with some work to do, another thread can step in and re-block on the selector, waiting to take the next batch of work to do (before the first thread finishes its work).
> A problem with this approach is that the first thread, before processing its ready I/O operations, must (while synchronized) remove interest in the operations that it is about to process, to prevent the next selecting thread from unblocking immediately because of the same ready I/O operations.  This requires continuous cancellation and re-registration of interest in I/O operations, particularly reads, which is problematic-- especially with a /dev/poll-based selector implementation (as is currently used on Solaris and Linux JDKs), which has an overhead proportional to the number of *changes* in the interest state.  (There is mention of this style being problematic in 6251637.)
> It would seem that a better approach would be to use only a single thread per selector, removing much of the need for updating the interest state.  Certainly this would seem beneficial if only one select thread is going to be used anyway (like the current implementation is hard-coded to do anyway).  To still support possible increased concurrency of I/O processing on multiprocessor machines, a better approach could be to have multiple select threads each having their own selector, and distribute the sockets being processed among the selectors in some balanced fashion.

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