mutex performance

Petri Helenius pete at he.iki.fi
Wed Nov 17 11:30:02 PST 2004


Daniel Eischen wrote:

>On Wed, 17 Nov 2004, Petri Helenius wrote:
>
>  
>
>>Do you feel that mutex performance could be improved from the current
>>2-3 million lock/unlock operations per second on uncontested mutexes on
>>~2.4Ghz prescott? Which seems to be about 1000 cycles per lock/unlock.
>>    
>>
>
>I'm not sure what you're trying to say above.
>  
>
I have this:
#include <pthread.h>

main()
{
  register int i;
  pthread_mutexattr_t attr;
  pthread_mutex_t onepacket;

  pthread_mutexattr_init (&attr);
  pthread_mutexattr_settype (&attr,PTHREAD_MUTEX_ERRORCHECK);

  pthread_mutex_init (&onepacket,&attr);

  for (i = 0; i < 20000000;i++)
    {
      pthread_mutex_lock (&onepacket);
      pthread_mutex_unlock (&onepacket);
    }
}

And run it:
 > gcc -O3 -std=c99 -g -march=pentiumpro mutextest.c -o mutextest -lthr
 > time ./mutextest
12.291u 0.000s 0:12.29 100.0%   5+189k 0+0io 0pf+0w
 > gcc -O3 -std=c99 -g -march=pentiumpro mutextest.c -o mutextest -lpthread
 > time ./mutextest
7.008u 0.000s 0:07.01 99.8%     5+230k 0+0io 0pf+0w
 > gcc -O3 -std=c99 -g -march=pentiumpro mutextest.c -o mutextest -lc_r
 > time ./mutextest
5.887u 0.000s 0:05.88 100.0%    5+389k 0+0io 0pf+0w


And I'm wondering how much I need to engineer around mutexes or holding 
them for longer and releasing just before yielding. I'm not saying it 
should/must be better, just trying to ask for the feel where to go.

>I want to change libpthread locks to drop the 80386 support
>and just use the atomic primitives for default mutex types.
>In 6.0, we'll also change all the mutexes, CVs, and semaphores
>so they aren't pointers -- that will save an indirection and
>also allow them to be process shared.
>  
>
Do you have patches or is this on planning stage?

Pete




More information about the freebsd-threads mailing list