This is the mail archive of the libstdc++@gcc.gnu.org mailing list for the libstdc++ project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [v3] mutex, condition_variable


On Wed, May 7, 2008 at 3:56 AM, Jakub Jelinek <jakub@redhat.com> wrote:
>
> 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.

I was thinking the same after I replied with the report of 2.cc being
broken.  I had forgot that threads are enabled by default under darwin
but disabled by default under linux.

Thanks,
Andrew Pinski


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]