Re: thread lib: solaris problems.

From: williamkempf_at_[hidden]
Date: 2001-10-29 14:30:22

--- 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