[concurrency-interest] On A Formal Definition of 'Data-Race'
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
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.
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.
> 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
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Concurrency-interest