pthread_cond_signal/wait is used in several places in ATS, including but not limited:
1) Logging system.
2) ProtectedQueue in event system.
3) RecProcess in stats system.
As we known, pthread_cond_signal() needs to take a lock. As such it'll cause more context switches than eventfd.
I wrote a simple benchmark program to compare the speed of eventfd and pthread_cond notify mechanism.
You can get the benchmark program from the attachment: https://issues.apache.org/jira/secure/attachment/12598570/eventfd_vs_pthread_cond_benchmark.tar.gz, and test it by yourself if interested.
What the program does is:
1) Create 10 producer threads and 1 consumer thread.
2) Producer threads will notify consumer concurrently in a loop.
3) The consumer thread will receive notification up to a given loop time.
Here is my testing result, the command line argument is loop time(1000000) of consumer:
We can see that eventfd is about 5 times faster than pthread_cond notify mechanism.