Implement heap based timer list #439
Conversation
|
Is it now better to just deactivate the timer and recycle it later on, Library users would definitely benefit from some best practices of |
|
It's unrelated to this change but little value in commentng on Any reasons why there is no consistent use of And were atomic variable operations considered with those recent |
jfriesse
force-pushed
the
timer-heap
branch
2 times, most recently
from
db6fe0b to
5e3e5ae
Compare
There is no change in this respect. "Just deactivate" timer is always faster, but that's not point of this PR. I have a version with freelist handy but I rather go step by step.
|
|
Added more locking so hopefully it is now lock safe. |
|
helgrind found a few things (it took several runs though!) ==23465== Helgrind, a thread error detector |
|
Helgrind error seemed to be bug in check_loop, so I've pushed fix for check_loop. |
Speed test is adding only 10000 items so it is reasonable fast even with sorted linked list implementation. Signed-off-by: Jan Friesse <jfriesse@redhat.com>
Previous timer was sorted list implementation of priority queue and very slow when number of timers increased. This is mostly not a problem because usually only few timers are used. But for application where bigger number of timers are needed it may become problem. Solution is to use binary heap based priority queue which is much faster. API is unchanged, just timerlist_destroy is added which should be called to free heap array. This function also destroys mutex (omitted when mutex was added). Signed-off-by: Jan Friesse <jfriesse@redhat.com>
Signed-off-by: Jan Friesse <jfriesse@redhat.com>
test_th was accesed both by main thread and loop_timer thread resulting in failure. Fix is to access test_tht in loop_timer thread. Signed-off-by: Jan Friesse <jfriesse@redhat.com>
|
An excellent improvement, thanks! |
https://build.opensuse.org/request/show/931807 by user yan_gao + dimstar_suse - Update to version 2.0.4+20211112.a2691b9 (v2.0.4): - poll: Don't log in a signal handler (gh#ClusterLabs/libqb##447) - Fix pthread returns (gh#ClusterLabs/libqb#444) - doxygen2man: print structure descriptions (gh#ClusterLabs/libqb#443) - Implement heap based timer list (gh#ClusterLabs/libqb#439) (forwarded request 931806 from yan_gao)
The most important fix in this release is that we no longer log errors inside the signal handler in loop_poll.c This could cause an application hang in some circumstances. Changelog is as follows: doxygen2man: print structure descriptions (ClusterLabs/libqb#443) Fix pthread returns (ClusterLabs/libqb#444) poll: Don't log in a signal handler (ClusterLabs/libqb#447) Bump library version for v2.0.4 Implement heap based timer list (ClusterLabs/libqb#439) build: Fix undefined pthread reference. (ClusterLabs/libqb#440) Signed-off-by: Wang Mingyu <wangmy@fujitsu.com> Signed-off-by: Khem Raj <raj.khem@gmail.com>
The most important fix in this release is that we no longer log errors inside the signal handler in loop_poll.c This could cause an application hang in some circumstances. Changelog is as follows: doxygen2man: print structure descriptions (ClusterLabs/libqb#443) Fix pthread returns (ClusterLabs/libqb#444) poll: Don't log in a signal handler (ClusterLabs/libqb#447) Bump library version for v2.0.4 Implement heap based timer list (ClusterLabs/libqb#439) build: Fix undefined pthread reference. (ClusterLabs/libqb#440) Signed-off-by: Wang Mingyu <wangmy@fujitsu.com> Signed-off-by: Khem Raj <raj.khem@gmail.com>
The most important fix in this release is that we no longer log errors inside the signal handler in loop_poll.c This could cause an application hang in some circumstances. Changelog is as follows: doxygen2man: print structure descriptions (ClusterLabs/libqb#443) Fix pthread returns (ClusterLabs/libqb#444) poll: Don't log in a signal handler (ClusterLabs/libqb#447) Bump library version for v2.0.4 Implement heap based timer list (ClusterLabs/libqb#439) build: Fix undefined pthread reference. (ClusterLabs/libqb#440) Signed-off-by: Wang Mingyu <wangmy@fujitsu.com> Signed-off-by: Khem Raj <raj.khem@gmail.com>
Previous timer was sorted list implementation of priority queue and very slow when number of timers increased. This is mostly not a problem because usually only few timers are used. But for application where bigger number of timers are needed it may become problem.
Solution is to use binary heap based priority queue which is much faster.
API is unchanged, just timerlist_destroy is added which should be called to free heap array. This function also destroys mutex (omitted when mutex was added).
It's worth noting that qb loop timer is using qb array which is (by default right now) limited to 65 536 entries and it is doing its own mapping of tlist entries and searching by simple for cycle (so lineary) so speed improvement here is really not big for real app.
I've used
check_tlist.cto measure improvement:Previous implementation:
New implementation:
For default (10000) speedup is not really that impressive:
Original:
Patched:
No matter what, I believe the extra code is worth - if not, then test suite for sure is ;)