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