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