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

Reply via email to