Re: thread lib: solaris problems.

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

As I sad, both issues caused by missing -mt.

ASSERT still exist even with -mt

Gennadiy.

--- In boost_at_y..., williamkempf_at_h... wrote:
> --- 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.
> 
> True in theory, but in practice this shouldn't really happen.  
> Implementations should strive to eliminate all spurious wakeups.  
> However, this does call into question my attempted test here.  I 
> don't think spurious wakeups are what's causing your asserts here, 
> but there's no way for me to gaurantee this.  I think we need a 
> pthreads expert and possibly a solaris expert as well to chime in 
on 
> this one.
> 
> > 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 :-(
> 
> Such a "smart" implementation really should return an error code 
> indicating timeout, as well as actually block the thread for the 
> given period.  Otherwise it could cause problems with timings in 
> conforming programs.  So I don't think this is the issue either.
> 
> Someone mentioned an -mt flag.  Does this effect things in any 
way?  
> I'm grasping at straws here, but I honestly don't know what's 
causing 
> this behavior on Solaris.
>  
> > 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???
> 
> I find it hard to believe that pthread_equal could be buggy, but 
> given your print statements above it certainly appears that this is 
> the case.  If tid == 1 and m_thread_id == 1 then pthread_equal
> (m_thread_id, tid) should return a true value and so the if should 
> never be executed and no exception should be thrown.  I'm sorry, 
I'm 
> not sure how to debug this one either.  I think we really do need a 
> platform expert whose familiar with Solaris's pthread 
implementation.
> 
> Bill Kempf