[infinispan-dev] deadlock detection - coin toss

[Jason T. Greene]

It turns out that it *IS* in-fact documented to be thread-safe:

http://java.sun.com/j2se/1.5.0/docs/api/java/util/Random.html#next(int)

However, it actually uses CAS in the impl.

Jason T. Greene wrote:
> Random is definitely thread-safe in the Sun derived JVMs, and probably 
> thread-safe in other JVMs. I would just use that.
> 
> Otherwise you could implement MT:
> http://en.wikipedia.org/wiki/Mersenne_twister
> 
> Mircea Markus wrote:
>> this is regarding: http://tinyurl.com/nunmyu
>> In order to be able to determine which tx should commit and which will 
>> rollback, I need to generate a coin toss for each node - a random number.
>> In order to do that I'm thinking to use on of the following:
>>
>> 1) use java.util.Random . The issue with this class is that it has an 
>> undocumented behavior when it comes to concurrent access, so I cannot 
>> rely on it behaving correctly if  I don't  enforce proper 
>> synchronization. I'm afraid this might become a bottleneck as all the 
>> prepapares requests might want to synchronize on it.
>> 2) Another approach would be to build an Random instance for each 
>> call. I made a test an the performance cost of new Random() + 
>> Random.nextLong is about 4 times bigger than call of random.nextLong 
>> only (on my laptop only), still about 15 mils for 1k creations
>> 3) use System.nanos. Even though the conflicting tx are created at the 
>> same time, the chance for it to happen in the same nanosecond is very 
>> small, I would say. Don't know how this works for all architectures, 
>> though...
>>
>> Any feedback much welcomed!
>>
>> Cheers,
>> Mircea
>>
>> _______________________________________________
>> infinispan-dev mailing list
>> infinispan-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/infinispan-dev
> 
> 


-- 
Jason T. Greene
JBoss, a division of Red Hat