This is the mail archive of the libc-help@sourceware.org mailing list for the glibc project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]