10 Jun
2020
10 Jun
'20
9:47 p.m.
We've been using uclibc 0.9.33.2 for yonks, and until now didn't have
any real reason to upgrade. However, we've run into a problem where
calls to pthread_cond_broadcast() sometimes take an extraordinarily
long time.
On a 400MHz ARM926, a call to pthread_cond_broadcast() usually takes
under 200us. However, occasionally it takes _far_ longer (up to
several tens of milliseconds). The caller is running with real-time
priority at a level higher than all other threads. The condition
variable is in shared RAM and the waiting threads (3-4 of them) are in
different processes. The long delays happen about 1 out of 100,000
calls. If you want to see the actual distribution of elapsed times
for the pthread_cond_broadcast() call, the elapsed time distribution
from one test run is at the bottom of this email.
Is this due to some fundamental design decision in the pthreads
implimentation? If so, is it still that way in uClibc-ng? Or is it a
bug that's likely been fixed?
Or is it actually a kernel issue? The kernel version is 2.6.33.7 with
PREEMPT patches.
Re-writing the code so that the "waiting" threads just poll a shared
counter which is incremented by the broadcaster eliminates the delay
problem but has other drawbacks.
ms occurances
------ ----------
0.000 3088767
0.122 8641750
0.244 1751
0.366 989
0.488 374
0.610 770
0.732 476
0.854 120
0.977 38
1.099 16
1.221 4
1.343 9
1.465 3
1.587 5
1.709 4
1.831 6
1.953 4
2.075 4
2.197 6
2.319 6
2.441 2
2.686 4
2.808 9
2.930 11
3.052 10
3.174 5
3.296 5
3.418 1
3.540 3
3.662 47
3.784 48
3.906 22
4.028 11
4.150 6
4.272 4
4.395 2
4.639 3
4.761 2
4.883 3
5.005 1
5.127 2
5.249 2
5.615 1
5.859 1
5.981 1
6.104 1
6.470 1
6.958 1
7.080 1
7.202 2
7.324 1
7.568 1
7.690 11
7.813 4
8.057 1
8.179 2
8.301 1
8.911 1
9.033 1
11.230 1
11.475 1
11.719 2
11.841 1
11.963 1
12.085 1
12.207 1
12.329 1
13.184 1
13.794 1
15.625 2