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
