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