t.lock2 issues

[David Relson]

Clint,

Given your comments, I decided to run the test several times and observe 
the variation of total runtime.

test 1 - with the suggested fix.  5 runs of 29 seconds each (no variation).
test 2 - code without any fix     5 runs of 27 seconds each (no variation)
test 3 - with fix and using time() as seed - 5 runs of 29, 27, 28, 27, 27 
seconds
           (timer resolution - 1 sec)
test 4 - with fix and gettimeofday() as seed - 5 runs of 22, 23, 24, 22, 22 
seconds
           (used tv_usec - microseconds)

It seems that using microseconds to seed the random number generator gives 
the lowest run time, which also raises the likelihood of lock 
contention.  This is a good thing as the goal of t.lock2 is to test 
database locking.

However, as this seems non-critical and we're close to having a stable 
release of bogofilter, any changes in this area can wait until after the 
release.

David

At 10:34 PM 1/31/03, Clint Adams wrote:

>----- Forwarded message from aaronl at vitelus.com -----
>
>Package: bogofilter
>Version: 0.10.1.4-1
>Severity: normal
>
>If bogofilter can not lock a database, it waits a random amount of
>time between MIN_SLEEP and MAX_SLEEP. At least, that's how it works in
>theory. A bug causes it to sleep for MIN_SLEEP microseconds virtually
>always. (MAX_SLEEP-MIN_SLEEP) is multiplied by rand(), and with the
>current values of MIN_SLEEP and MAX_SLEEP this almost always causes a
>long integer overflow on 32 bit systems. The result is then divided by
>(RAND_MAX+1.0), but as the maximum value of a signed long integer on
>my platform is equal to RAND_MAX, this division is useless and will
>always have a zero result. The patch below solves the problem by doing
>the multiplication with floating point arithmetic, preventing integer
>overflow.
>
>Note that bogofilter does not seem to seed the rand() function. This
>shouldn't really be necessary, but it does make the t.lock2 test less
>effective, since every instance of bogofilter will use the same random
>number sequence. (Alternately, you can view this as beneficial to the
>test, since every bogofilter process will sleep for the same time and
>thus there will be more lock contention when they awake simultaneously).