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

Nathan Reynolds nathan.reynolds at oracle.com
Tue Apr 16 17:16:42 EDT 2013

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

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

More information about the Concurrency-interest mailing list