[OpenSTA-devel] Re: When is Random not random?

[Daniel S. <da...@Op...>]

Mark Elam wrote:
> Yes, but we're calling srand(A1),rand(),srand(a2),rand(),srand(a3)
> ...  So the 'initialize with seed' is occuring before each call to
> rand, which should reset the seed before each call.  However if
> another thread called srand() before the first thread rand() had
> occured I can see the problem you are describing which is why I
> wondered whether just making the srand(),rand() pair atomic (with a
> mutex) would solve the issue.  As rand() would always be called
> after a reset with srand() using the same seed this should give the
> same sequence.

I think you are correct Mark.  I've tried to stimulate this potential
concurrency and timing issue to occur using some contrived scripts
and I can't seem to - that's not to say it won't happen, just that it
seems it is unlikely to happen.  Maybe it's something to do with how
the work is assigned to the threads in a Test Executer, or the
potential points of context switch on my single CPU test host.

The above doesn't matter though, as the whole method of always
reseeding is obviously a really bad way of generating "random"
numbers...  I created a little script like this:
  Definitions
    CHARACTER*512 USER_AGENT
    INTEGER USE_PAGE_TIMERS
    INTEGER RandInt(1-10), RANDOM
    INTEGER Occurrence[10]
    INTEGER Idx
  Code
    Entry[USER_AGENT,USE_PAGE_TIMERS]
    DO Idx = 1, 1000
        GENERATE RandInt
        SET Occurrence[RandInt] = Occurrence[RandInt] + 1
    ENDDO
    DO Idx = 1, 10
       LOG Idx, " occurred ", Occurrence[Idx], " times"
    ENDDO
Running this, very simple, test several times was enough to tell me
that there is definitely not an equal probabiliy of getting each of
the possible returns of RandInt.  I found by, unscientifically,
eyeing the results that there was always much more chance of getting
a 1, 3, or 8; and much less of a chance of getting 2, 5, or 7... not
good!

Obviously the behavior of RANDOM variables needs fixing - it looks
like there's 3 seperate bugs that can be addressed in one update:
 - limited range of returns (bug#415144)
 - less than random distribution of returns (not logged)
 - small chance of REPEATABLE failing due to timing (not logged)
I'm still concerned about keeping the old (bad) behavior of
REPEATABLE as default, with a logged warning, that can then have the
good behavior, or warning, defeated using the .ini file.  My feeling
is that it is not worthwhile keeping the behavior of regular RANDOM
but other opinions are welcome.

I'm starting to put a shortlist together for a 1.4.4 release and it
would be great if Peter (or someone) could donate some code to get
these problems, at least partially, fixed for this release.

Cheers
/dan
-- 
Daniel Sutcliffe <Da...@Op...>
  OpenSTA part-time caretaker - http://OpenSTA.org/