This is the mail archive of the
libc-help@sourceware.org
mailing list for the glibc project.
random performance of sem_post function
- From: "Maury, Olivier" <Olivier_Maury at mentor dot com>
- To: "libc-help at sourceware dot org" <libc-help at sourceware dot org>
- Date: Fri, 4 Jan 2013 17:21:21 +0000
- Subject: random performance of sem_post function
Hi & Happy New Year !
I'm having some trouble understanding the performance of the sem_post function.
I've two executable that use a same piece of code (statically linked) that manage some posix threads: that includes the threads synchronization but also the code of the tasks performed by the threads.
When my threads have nothing to do they wait using sem_wait. Each thread has its own semaphore, so basically for the thread i, it will do sem_wait(my_sem[i]).
When the main thread assign a new task to the other threads it will simply do a sem_post(my_sem[i]) to wake up the ith thread.
What is very strange is that this simple sem_post function is not tacking the same amount of time in both executables. In one of them the order of magnitude of the function call is almost all the time about 1e-5s while in the other one it's goes from 1e-5s (very rare) to 1e-2s (quite often).
I was thinking that maybe that was because in one executable I would spend less time in a sequential part of the code. So I added a 'nop' loop in the main thread before I call the sem_post functions to make sure that I'd spend about the same time in that sequential code in both executable. But it didn't change the behavior of the same_post function...
Any idea of what could happen here ? As far as I understand the sem_post assembly code, it shouldn't be blocking... The worst case would be to enter syscall with FUTEX_WAKE but it should be the case with my two executable now that I have put that 'nop' loop to make the main thread waiting for 1 or 2s before kicking the threads.
Regards
Olivier