river-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Peter <j...@zeus.net.au>
Subject Re: ThreadPool calling Thread.setName
Date Mon, 29 Apr 2013 07:41:26 GMT

----- Original message -----
> 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.

Perhaps specialist knowledge would have been more appropriate :)

>
> 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.

We owe those people, their work makes ours much easier :)


>
> > 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
>


Thanks for the feedback, that was a difficult decision to make.

Peter.

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message