river-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Patricia Shanahan <p...@acm.org>
Subject Re: ThreadPool calling Thread.setName
Date Fri, 26 Apr 2013 15:20:30 GMT
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 


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.

View raw message