Re: test-lock taking a long time?

[Bruno Haible]

Hi Simon,

> Has anyone noticed that test-lock takes a long time to complete on some
> systems?

Yes, on Solaris 11 for example it is particularly slow.

> Is there some scaling in the test that makes it take longer for
> multi-cpu machines?  I didn't see any from a quick look.

No, the test has a fixed number of threads, a fixed number of shared
objects (bank accounts), and a fixed number of modifications per thread.

> On my laptop it is fast:
> 
> address@hidden:~/src/gnutls/gl/tests master$ time ./test-lock
> Starting test_lock ... OK
> Starting test_rwlock ... OK
> Starting test_recursive_lock ... OK
> Starting test_once ... OK
> 
> real  0m1.724s
> user  0m1.044s
> sys   0m4.708s
> address@hidden:~/src/gnutls/gl/tests master$ 
> 
> However on a otherwise idle machine with 2xE5520's (resulting in 16
> virtual CPUs), it takes much longer:
> 
> address@hidden:~/gnutls-3.0.12/gl/tests$ time ./test-lock 
> Starting test_lock ... OK
> Starting test_rwlock ... OK
> Starting test_recursive_lock ... OK
> Starting test_once ... OK
> 
> real  1m49.893s
> user  1m31.874s
> sys   16m4.056s

It can depend on many factors: Which kind of scheduler is used. How much
time it takes to switch a CPU to a different thread. How much the
"affinity" of threads to CPUs is preserved. How good the implementation
of locks in libc is.

I don't know enough about the inner workings of multithreading to analyze
this.

Bruno