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