Boost logo

Boost :

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/


Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk