[jboss-dev] Thread safety problems

[David M. Lloyd]

When writing an API or SPI it is absolutely critical that all the elements 
of that API or SPI are thoroughly documented with any information related 
to the thread safety (or lack thereof) of that element.  We have a great 
deal of code (and I'm talking critical, core stuff) out there with little 
or no javadoc at all, let alone thread safety information in said 
documentation.  This creates the possibility for situations like SPIs which 
can end up being implemented with completely wrong thread safety semantics, 
basically leaving time bombs in the code.  See 
http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4226025 for one 
recent example.

We still have way too much code doing double-checked locking, or using 
locks in strange or non-optimal ways, or using thread interruption wrong, 
or making wrong assumptions about the JMM.  Own and read this book: 
http://jcip.net/ - don't think you understand concurrency until you have 
done so - seriously.

Thread interruption in particular is easy to do right.  When handling 
InterruptedException, you basically have two choices.  Either rethrow it 
*directly* (absolutely no re-wrapping allowed!), or re-set the thread 
interrupt status (either way, there's no need to log the exception - that 
will just lead to noise).  If you do the latter, you have a choice as to 
whether you want to cancel or short-circuit the current operation (which 
should be done in as sane and predictable a way as possible - don't just 
blow up with a RuntimeException!), or complete what you're doing. 
Interruption happens guys, that's how thread pools are usually shut down 
and tasks (which your code may be a part of) are cancelled.

- DML