[concurrency-interest] On A Formal Definition of 'Data-Race'

oleksandr otenko oleksandr.otenko at oracle.com
Tue Apr 16 17:30:38 EDT 2013


Yes. I am only saying that technically it is a race, since the question 
was what a race is. But is it harmful? No. That's why early on in the 
discussion some people made a distinction between a race and broken logic.

Alex


On 16/04/2013 22:16, Nathan Reynolds wrote:
> Let's frame this in terms of ACID. Properly-used locks provide the A, 
> C and I of ACID.  A harmful data race can be viewed as a violation of 
> atomicity, consistency or isolation.  Many data races can exist 
> without violating A, C or I and hence be harmless.  These data races 
> are great ways to improve scalability.  Idempotent operations seem to 
> be easiest to make racy yet harmless.
>
> Setting the String hash value is racy yet harmless.  It doesn't 
> violate atomicity since the field changes without any intermediate 
> values.  The field either has 0 or the proper value (assuming word 
> tearing can't happen).  It doesn't violate consistency since the field 
> can only be in two valid states (i.e. 0 or the proper value).  It 
> doesn't violate isolation since "concurrent execution results in a 
> state that would be obtained if executed serially" (Wikipedia).
>
> Let's revisit the following example in this framework.
>
> > Thread 1                     Thread 2
> > this.shared = 10            local = this.shared
>
> > Is this "racy"?
>
> Both operations on Thread 1 and 2 are atomic (assuming word tearing 
> can't happen).
>
> As far as consistency is concerned, that depends upon the value of 
> "this.shared" before execution.  Is "this.shared" in a valid state to 
> begin with (i.e. is is consistent)?  If so, then Thread 2 will end up 
> in a consistent state.  If not, then it is a harmful data race.  For 
> example, if an object's reference is published before the constructor 
> finishes, then Thread 1 could be executing in the constructor and 
> Thread 2 is accessing the partially-constructed object.  The object's 
> state is inconsistent (i.e. this.shared == 0 is an invalid state).
>
> It has isolation.  If you execute Thread 1 and Thread 2 concurrently, 
> you get the same result as if you had executed one first and the other 
> second.  Of course, depending upon timing, the system state will end 
> up in one of two states: local == 10 or local == /previous value/.  
> The system can't end up in a different third state.
>
> Nathan Reynolds 
> <http://psr.us.oracle.com/wiki/index.php/User:Nathan_Reynolds> | 
> Architect | 602.333.9091
> Oracle PSR Engineering <http://psr.us.oracle.com/> | Server Technology
> On 4/16/2013 12:33 PM, oleksandr otenko wrote:
>> Technically, setting hash value is racy. It is the same value, but 
>> the writes race.
>>
>> Alex
>>
>> On 16/04/2013 19:57, thurstonn wrote:
>>> Just curious, how is String#hashCode() racy?
>>> Strings are immutable in java; I looked at the code a bit and I didn't see
>>> anything that looked racy.
>>> The only thing I guess could be:
>>> private char[] value
>>>
>>>
>>> Although that array is never modified in the String class, so . . .
>>
>>
>> _______________________________________________
>> Concurrency-interest mailing list
>> Concurrency-interest at cs.oswego.edu
>> http://cs.oswego.edu/mailman/listinfo/concurrency-interest
>
>
>
> _______________________________________________
> Concurrency-interest mailing list
> Concurrency-interest at cs.oswego.edu
> http://cs.oswego.edu/mailman/listinfo/concurrency-interest

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://cs.oswego.edu/pipermail/concurrency-interest/attachments/20130416/ab77fc50/attachment.html>


More information about the Concurrency-interest mailing list