hc-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Oleg Kalnichevski <ol...@apache.org>
Subject Re: svn commit: r724147
Date Sun, 07 Dec 2008 19:20:10 GMT
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: dev-unsubscribe@hc.apache.org
For additional commands, e-mail: dev-help@hc.apache.org


Mime
View raw message