David M. Lloyd wrote:
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.
Well said. Every contributor should read this book, it is essential
knowledge.
I will also add that all new designs/enhancements must take thread
interaction into consideration. It is much harder to retrofit an
existing API/implementation to be safe and efficient after it has been
completed.
If you aren't sure how to solve a threading problem, or want to validate
your design please ask here or on the forums! We have many experts in
this area.
--
Jason T. Greene
JBoss, a division of Red Hat