Am 25.04.2017 um 17:27 schrieb Yann Ylavic:
On Tue, Apr 25, 2017 at 9:55 AM, Yann Ylavic <ylavic....@gmail.com> wrote:
The attached patch prevents this by looping on
pthread_cond_[timed]wait() until the condition is satisfied.
Would you please try it?
Committed to trunk (only) in r1792622, for easier/wider testing possibly.
I applied r1792621, r1792622 and r1792625 and tested on Solaris 8 and
10. For the test I tried with and without "--enable-timedlocks". I also
added the hard disabling of (the broken) pthread_mutex_timedlock on
Solaris 10 before testing.
The tests do no longer hang. The only strangeness is without
"--enable-timedlocks" on Solaris 10 I get some "error" lines in the "APR
Lock Performance Test" section (testlockperf.c) for the tests of type
"(TIMED)":
...
apr_thread_mutex_t Tests
Initializing the apr_thread_mutex_t (TIMED) OK
Starting 2 threads OK
microseconds: 697841 usec
error: counter = 1837161
...
apr_thread_mutex_t Tests
Initializing the apr_thread_mutex_t (TIMED) OK
Starting 3 threads OK
microseconds: 1194129 usec
error: counter = 2562724
...
apr_thread_mutex_t Tests
Initializing the apr_thread_mutex_t (TIMED) OK
Starting 4 threads OK
microseconds: 1890774 usec
error: counter = 3462599
...
apr_thread_mutex_t Tests
Initializing the apr_thread_mutex_t (TIMED) OK
Starting 5 threads OK
microseconds: 3713934 usec
error: counter = 4897388
...
apr_thread_mutex_t Tests
Initializing the apr_thread_mutex_t (TIMED) OK
Starting 6 threads OK
microseconds: 2638046 usec
error: counter = 4479066
...
So these tests end too early. The counter should be 1000000*#threads,
but it is always smaller.
I do not see such "error" lines for Linux.
Regards,
Rainer