Sam Berlin wrote:
I'm fairly certain this change will have unintended consequences. One
of the quirks about interestOps is that they are legally allowed to be
set from any thread -- this is what allows a currently-blocked
selector to wakeup seeing some new interestOps (when coupled with a
selector.wakeup). The simple fix here would be to make the new local
interestOps variable volatile, but that has subtle bugs. All
mutations of interestOps require a read, a stack-local mutate and then
a set, which means that it's possible for one thread to begin a read &
mutate, then another to begin the same procedure. When context
returns to the first thread, the resulting set loses the mutate from
the second thread. It's a classic thread-safety problem due to lack
of a critical section.
It's possible to do some sort of CaS non-blocking operation similar to
how the internals of AtomicInteger implement getAndDecrement,
getAndAdd, etc... but it's far easier to just re-add the critical
section (ie, 'synchronized') around usage of interestOps.
Good catch. My bad. I re-introduced the critical section around
interestOps and made interestOps volatile. Please review [1]
The reason I have done this change is to make it possible for the I/O
session to defer mutation of SelectionKey's interestOps to the I/O
dispatch in order to avoid the dead-lock condition described in
HTTPCORE-155 [2] when running on buggy JREs such as IBM's
Oleg
[1] http://svn.apache.org/viewvc?rev=724177&view=rev
[2] https://issues.apache.org/jira/browse/HTTPCORE-155
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
