Callback Based Selectors

Alan Bateman Alan.Bateman at oracle.com
Wed Mar 28 14:32:05 UTC 2018


On 20/03/2018 01:57, David Lloyd wrote:
> :
> Thinking about this some more, I am coming to believe that this is the
> crux of the locking problems we routinely encounter.  If we can get to
> a point where we can, in specification, state that select ops (or
> maybe even just the new select op(s)) will only hold the selector lock
> while blocking, then we are in an ideal situation as far as frameworks
> go because the aforementioned strategy (for channel registration which
> occurs concurrently to a selection operation) of "register and wakeup"
> will always work.
I agree that registering when there is selection operation in progress 
is a pain, it forces everyone to follow the idiom to synchronize on a 
gate object.

I looked into the API/spec implications of changing this and it's not 
too bad. The recent changes to the Selector implementations means it has 
little impact as all the implementations in the JDK now handle new 
registrations and changes to interest ops as part of the selection 
operation.

In terms of compatibility then the only concern is code that 
synchronizes on the key set or selected-key to prevent keys being added 
by concurrent registrations or selection operations (e.g. code processes 
and removes all keys from the selected-key set and then asserts that the 
selected-key is empty). If this is an issue then registration could 
continue to synchronize, and the selection operation could limit is 
synchronization to when it needs to add to the selected-key set. The 
other aspect to compatibility is other SelectorProvider (and Selector) 
implementations although I've never come across complete implementations.

Here's prototype spec changes to see how it might look:
http://cr.openjdk.java.net/~alanb/concurrent-selector-register/webrev/

New registrations would be register+wakeup, changes to interest ops can 
be interestOps+wakeup.

I think it will need analysis of existing usages of the API to fully 
understand the compatibility impact of changing anything here. Also 
relaxing the locking with help with the select(Consumer<SelectionKey>) 
API that Richard has proposed.

-Alan




More information about the nio-dev mailing list