Re: [infinispan-dev] deadlock detection - coin toss

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(a)lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/infinispan-dev > >