thread lib: solaris problems.

From: John Maddock (John_Maddock_at_[hidden])
Date: 2001-10-26 06:13:14

Bill,

First the good news, the thread lib looks great on linux and on Mac OS X. 
Unfortunately I'm seeing all kinds of failures on solaris.

First of all, boost.function won't build with sunpro 5.3, I haven't figured
out why yet - any sunpro experts out there?

When build with gcc, it all builds fine but I see a bunch of runtime
errors:

**** test failed: condition.timed_wait(lock, xt) == false, file:
test/test_thread.cpp, line: 44

**** test failed: condition.timed_wait(lock, xt) == false, file:
test/test_thread.cpp, line: 44

**** test failed: condition.timed_wait(lock, xt) == false, file:
test/test_thread.cpp, line: 83

**** test failed: condition.timed_wait(lock, xt) == false, file:
test/test_thread.cpp, line: 44

**** test failed: condition.timed_wait(lock, xt) == false, file:
test/test_thread.cpp, line: 83

**** test failed: condition.timed_wait(lock, xt) == false, file:
test/test_thread.cpp, line: 131

**** test failed: condition.timed_wait(lock, xt) == false, file:
test/test_thread.cpp, line: 44
Abort (core dumped)

First the failed tests - I've checked and pthread_cond_timedwait is
returning zero, even though the condition variable is never signalled.  The
trouble is if I've read the docs correctly pthread_cond_timedwait can
return zero any time it wants to (a spurious wakeup).  In effect the client
would end up polling the condition until it becomes true.

More to the point, a clever pthreads implementation would be able to tell
that the condition variable in the test program could never be signalled
(because there are nor other non-blocked threads in the process that could
signal it), and therefore either return an error code immediately or else
return zero immediately.  I've no idea what you do about this though :-(

Finally there is an abort occurring from an uncaught exception from 

boost::recursive_mutex::do_unlock

heres the gdb debug session:

boost::recursive_mutex::do_unlock (this=0xffbef8d8)
    at src/recursive_mutex.cpp:344
344         int res = 0;
(gdb)
345         res = pthread_mutex_lock(&m_mutex);
(gdb)
346         assert(res == 0);
(gdb)
348         pthread_t tid = pthread_self();
(gdb)
349         if (m_valid_id && !pthread_equal(m_thread_id, tid))
(gdb)
351             res = pthread_mutex_unlock(&m_mutex);
(gdb)
352             assert(res == 0);
(gdb)
353             throw lock_error();
(gdb) print tid
$2 = 1
(gdb) print m_valid_id
$3 = true
(gdb) print m_thread_id
$4 = 1

which implies that pthread_equal is buggy???

- John Maddock
http://ourworld.compuserve.com/homepages/john_maddock/