Re: thread lib: solaris problems.

From: Gennadiy E. Rozental (rogeeff_at_[hidden])
Date: 2001-10-29 12:04:14

this was because of absent -mt, isn't it?

And I am getting the same ASSERT as you.

Gennadiy.

--- In boost_at_y..., John Maddock <John_Maddock_at_c...> wrote:
> 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/