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 Sun, 28 Apr 2013 13:34:06 GMT
On 4/27/2013 4:19 PM, Peter Firmstone wrote:
...
> But we are starting to encroach into territory where angels fear to
> tread, requiring genius reasoning powers.  For 99% of cases I'd like to
> stick to simple rules that avoid reasoning about consequences of data
> races.  This will make it easier for developers to reason about the
> behaviour of River.  Throw in the asynchronous nature of the network and
> we've already got a high enough bar for developers to jump over.

I don't claim genius reasoning powers, but I have spent a lot of time 
thinking about the issues of memory order and concurrency. It used to be 
my job - I worked for Sun Microsystems as an architect designing large 
multiprocessor servers.

A lot of the issues that can arise in software through code reordering 
can also happen in multiprocessor hardware. Any consistent relative 
ordering between an access by processor 40 to memory module 10 and an 
access by processor 22 to memory module 3 happens because someone worked 
very hard to make it happen.

> This case falls into that other 1%, so yes I'll be changing it back to
> allow the data race, but I believe this is an exceptional case because
> there is no other way to perform that operation safely, the likelihood
> of error remains low and I believe there is a good chance it'll be fixed
> in the next version of Java.

I agree with this view. It is a very exceptional case, and I strongly 
agree with the general strategy of getting rid of data races.

I believe it would be possible to subclass Thread to add synchronized 
methods safeSetName() and safeGetName(), and override its toString to 
use safeGetName(). I would suggest doing this if it did not seem likely 
to get fixed in the next version.

Patricia


Mime
View raw message