Re: [Boost-users] Re: boost::thread::join causes assertion (pthreads)

From: David E. Konerding DSD staff (dekonerding_at_[hidden])
Date: 2005-03-21 14:52:20

Kevin Wheatley wrote:

>Thorsten Froehlich wrote:
>  
>
>>I noticed that when using thread::join and the thread has already completed,
>>at least on Mac OS X using pthreads, pthread_join returns EINVAL, thus
>>triggering the assertion res == 0.  Is this intentional or a bug?
>>    
>>
>
>I think this is intentional as the same occurs for all 3 platforms
>Threads supports (personally used on Win32 and Linux). I'd prefer to
>see the return codes from the various platforms turned into a platform
>independent error code but I'm not sure what the various possibilities
>are and if they are small enough to be usefully consolidatable into
>true platform indepenant codes. You can of cause compile in release
>mode with the assertions turned off, but its a pain when debugging.
>
>I tried asking about this on the developer list but I guess people are
>busy (isn't everybody :-) or ignoring me (paranoid!).
>
>Kevin
>
>  
>

The following is not strictly Boost specific, but might be helpful:

Mac OS X is much more sensitive to thread programming errors than Linux 
(at least Red Hat 9; there could be other platforms with more compliant 
and useful pthreads implementations) .  We discovered a threading bug in our
code only after attemping to port to Mac OS X and getting various thread 
errors.  In each case,
we found out that it was a real thread bug in our code (for exmaple, 
attemping to lock a locked mutex, or unlocking an unlocked mutex) and 
Linux simply passed through that line of code with no error messages, 
while OS X crashed immediately with a helpful error message. 

ACtually, now that I read the man page (pthread_mutex_lock)again, I see 
that LinuxThreads (and maybe NPTL) uses "fast" mutex kinds by default, 
which don't check for certain error conditions.

In the end, we were able to reproduce the problem using valgrind on 
Linux IA32.

Dave