Major Description
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:
[eventfd_vs_pthread_cond_benchmark]$ ls main.cc Makefile [eventfd_vs_pthread_cond_benchmark]$ make g++ -g -o eventfd_test main.cc -DHAVE_EVENTFD -lpthread g++ -g -o pthread_cond_test main.cc -lpthread [eventfd_vs_pthread_cond_benchmark]$ ls eventfd_test main.cc Makefile pthread_cond_test [eventfd_vs_pthread_cond_benchmark]$ time ./eventfd_test 1000000 real 0m11.644s user 0m1.517s sys 1m31.179s [eventfd_vs_pthread_cond_benchmark]$ time ./pthread_cond_test 1000000 real 0m57.438s user 0m30.152s sys 6m7.289s
We can see that eventfd is about 5 times faster than pthread_cond notify mechanism.