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: > > jas@latte:~/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 > jas@latte:~/src/gnutls/gl/tests master$ > > However on a otherwise idle machine with 2xE5520's (resulting in 16 > virtual CPUs), it takes much longer: > > jas@leo:~/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
