Re: [v3] mutex, condition_variable

[Jakub Jelinek <jakub at redhat dot com>]

On Wed, May 07, 2008 at 03:12:11AM -0700, Andrew Pinski wrote:
> On Tue, May 6, 2008 at 2:22 PM, Benjamin Kosnik <bkoz@redhat.com> wrote:
> >
> >  This adds in preliminary support for C++0x mutex/condition_variable, as
> >  first posted here:
> >  http://gcc.gnu.org/ml/libstdc++/2008-03/msg00059.html
> >
> >  Large parts of mutex are taken from the existing support in
> >  ext/concurrence.h, which explains the copyright dates on that file.
> 
> 30_threads/mutex/try_lock/2.cc  fails on darwin because try_lock
> throws an exception.
> pthread_mutex_trylock returns EBUSY which is correct as the mutex is
> already locked.  I have not looked into what the C++0x standard says
> though about what happens when try_lock fails because it is already
> locked but the POSIX standard is clear what the behavior of
> pthread_mutex_trylock is here.
> The pthread_mutex_trylock() function shall fail if:
> [EBUSY]
> The mutex could not be acquired because it was already locked.
> 
> I think GNU/Linux is not returning the correct value here as far as I
> can tell from reading the POSIX standard.

The problem is different actually.  The 30_threads tests aren't linked
with -lpthread, which means !__gthread_active_p ().  At least
gthr-posix.h in that case doesn't do any locking and always returns 0
in all the functions.  If libstdc++ needs something different
in single-threaded programs that don't have -lpthread linked in, then
it will need to use
if (__gthread_active_p ()) e = gthread_mutex_trylock (mutex);
else { do some simplistic non-atomic locking }
etc.  And the try_lock/2.cc testcase is buggy of course, when the mutex
isn't recursive, try_lock on an already locked mutex is supposed to fail.

	Jakub