There's an interesting paper submitted to the concurrency interest mail
list explaining why data races are bad.
I'll go over the list and find the link for you.
Basically there are consequences worse than semantic failure alone.
The river code itself doesn't attempt to log the thread's name, but it
is useful, although not essential in thread dumps.
Yes, it's a trade off.
Regards,
Peter.
Patricia Shanahan wrote:
I've looked at the source code. The field "name" that is shared
between threads doing getName or setName on a given Thread is a
reference. Writes and reads of references are always atomic.
The worst that could happen is that the change to the name does not
propagate to all threads that might display information about the
thread. The proposed fix ensures that worst case outcome happens all
the time.
Patricia
On 4/26/2013 5:44 AM, Greg Trasuk wrote:
I'm curious, as I don't see any indication in the Javadocs that
setName() isn't thread safe. Is there another reference that calls that
out? And what would be the failure mode, apart from a mangled string in
a log output?
Personally, if the potential failure mode wasn't onerous, I'd opt for
more descriptive logging. Comprehensibility is everything when you're
troubleshooting.
Cheers,
Greg.
On Fri, 2013-04-26 at 05:48, Peter Firmstone wrote:
Hope you don't mind, I've removed the call to Thread.setName in
com.sun.jini.ThreadPool
As a result threads will be less descriptive, unfortunately setName
isn't thread safe, it's final and cannot be overridden. Thread.getName
is only thread safe if a Thread's name isn't changed after publication.
ThreadPool was the only instance of Thread.setName in River.
Regards,
Peter.
