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

oleksandr otenko oleksandr.otenko at oracle.com
Tue Apr 16 18:18:39 EDT 2013


Serializability is not the only consistency model.

You need to consider what equality means. If equality is defined as 
identity, two racy writes are always broken logic. If equality is 
defined as isomorphism, some racy writes do not break logic.


Alex


On 16/04/2013 22:58, thurstonn wrote:
> Nathan Reynolds-2 wrote
>> 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
> True.  But if you apply a serialization graph to the two "transactions"
> (executions), the SG is acyclic ==> non serializable.  Normally you don't
> consider the case where all of the transactions (threads) write the same
> value to the shared data item
> <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 .oswego
>> http://cs.oswego.edu/mailman/listinfo/concurrency-interest
>
> _______________________________________________
> Concurrency-interest mailing list
> Concurrency-interest at .oswego
> http://cs.oswego.edu/mailman/listinfo/concurrency-interest
>
>
>
>
>
> --
> View this message in context: http://jsr166-concurrency.10961.n7.nabble.com/On-A-Formal-Definition-of-Data-Race-tp9408p9455.html
> Sent from the JSR166 Concurrency mailing list archive at Nabble.com.
> _______________________________________________
> 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/9098089a/attachment.html>


More information about the Concurrency-interest mailing list