[infinispan-dev] deadlock detection - coin toss

[Mircea Markus]

Ah, I missed that - thanks!

Jason T. Greene wrote:
> 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
>>
>>
>
>