river-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Gregg Wonderly <ge...@cox.net>
Subject Re: ThreadPool calling Thread.setName
Date Mon, 29 Apr 2013 21:25:53 GMT

On Apr 28, 2013, at 8:34 AM, Patricia Shanahan <pats@acm.org> wrote:

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

Note that there is detection of "thread subclassing" in the security management which causes
more "checking" to occur Thread.isCCLOverriden() checks for a subclass, and checks to see
exactly which methods are overridden, and then requires an additional permission to override
some of those methods.

Gregg Wonderly
View raw message