[reSIProcate] Random.cxx and MultiCore systems

[Alan Hawrylyshen]

I am still quite tempted to prove what the failure is with a minimal  
test driver. I fear that it might be something slightly more  
insidious. So, once we can cause this to happen at-will, we can  
address the appropriate root cause. Is this something that can be  
checked easily? Anyone?

I have a test driver that fails on a dual core intel platform, gcc  
4.0.1, Mac OS X 10.5.2
This will fail around the 100 mark in the progress output (but I have  
waited much longer).
Let it run for a while and see.
This will abort when two successive calls to random() match.

I would expect this to be unlikely, but should we check this on a  
single processor / single core system?
Does it happen more often on dual core or SMP systems?
Aron - can you try this on your platform?
Please run it a LOT and see if the time-to-run varies greatly or if it  
fails reliably.

Thanks
Alan

--

#include <stdio.h>
#include <time.h>
#include <unistd.h>
#include <stdlib.h>
#include <string.h>

int
main()
{
     unsigned long long t = 0;
     unsigned long l1 = (unsigned long)random();

     srandom(time(0));

     unsigned long l2 = 0UL;
     while (3)
         {

             l2 = (unsigned long)random();

             if ( l1 == l2 ){
                 printf("tot: %llu\nl1: %lu\nl2: %lu\n",t,l1,l2);
                 abort();
             }
             l1 = l2;
             t++;
             const int modulator = 10000000L;
             if (!(t % modulator)) {
                 printf("%llu...\r",(t/modulator));
                 fflush(stdout);
             }
         }

     return 0;
}


Alan

On 19-Mar-08, at 15:56 , Aron Rosenberg wrote:

> The only thing that I could think of is to use the new random_r and  
> srand_r functions instead of random and srand. The glibc _r ones  
> force the application to keep the “seed” value which might make it  
> immune to the caching problem.
>
> The issue with this approach was that the entire Random() class is  
> static although you could just add a class wide static variable to  
> hold the new userland data.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://list.resiprocate.org/pipermail/resiprocate-devel/attachments/20080320/7818b33d/attachment.htm>