On Fri, Apr 28, 2017 at 12:41 AM, Rainer Jung <rainer.j...@kippdata.de> wrote: > 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.
Thanks for testing, so proc tests look good now right? > 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. I did the same changes (as r1792622) for thread-mutex in r1794266, better with it applied? Thanks, Yann.
