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