Bug 342 - Threads hang after condvar destruction
Summary: Threads hang after condvar destruction
Status: RESOLVED FIXED
Alias: None
Product: glibc
Classification: Unclassified
Component: nptl (show other bugs)
Version: unspecified
: P2 normal
Target Milestone: ---
Assignee: Ulrich Drepper
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2004-08-23 13:15 UTC by Sebastien Decugis
Modified: 2014-05-28 19:42 UTC (History)
1 user (show)

See Also:
Host:
Target:
Build: gcc3.4.1
Last reconfirmed:


Attachments
This files shows the problem (5.22 KB, text/x-csrc)
2004-08-23 13:31 UTC, Sebastien Decugis
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Sebastien Decugis 2004-08-23 13:15:56 UTC
The POSIX standard requires that it is safe to destroy a condvar when no more
threads are blocked on it, even if the threads are still inside the
pthread_cond_{timed}wait routine. Please refer to the pthread_cond_destroy()
page and especially to the Example section.

The current implementation does not respect this assertion. The routines
pthread_cond_wait or timedwait still need to access some condition data, but the
pthread_cond_destroy succeeds anyway. The result is a hang when the memory of
the destroyed condvar is re-used.

Maybe the pthread_cond_destroy should block until every other thread leaves the
pthread_cond_* routines, as it is done in the barriers? -- I'm not sure if this
is possible...

Regards,
Sebastien.
Comment 1 Sebastien Decugis 2004-08-23 13:31:19 UTC
Created attachment 170 [details]
This files shows the problem

This file would return 0 if the implementation conformed to POSIX. It hang for
120 sec then timeout currently.
Comment 2 Jakub Jelinek 2004-09-03 08:08:58 UTC
Should be fixed in CVS.
Comment 3 Sundararajan 2006-03-29 15:25:32 UTC
I am using a RedHat Linux Enterprise version.

uname -a would give
Linux xyz220 2.6.9-22.EL #1 Mon Sep 19 18:20:28 EDT 2005 i686 i686 i386 GNU/Linux

I get the hang state on using the call pthread_cond_destroy

if( pthread_mutex_destroy(&lock->mutex) == EBUSY)
    {
       printf(xfp, "\n this is after destroy mutex ebusy");
    }
if (lock->recursive) {
pthread_cond_destroy ( &lock->cv )
}

Can I know if this has been resolved , if so, what;s the patch information.
if not, what;s the proposed solution.

thanks and regards
sundar
Comment 4 Ulrich Drepper 2006-04-01 20:03:07 UTC
Stop asking questions about distributions here.  If you have problems with the
distribution ask the paid support.  If you don't pay for support ask in some
forum dedicated to that distribution.
Comment 5 Jackie Rosen 2014-02-16 18:27:54 UTC Comment hidden (spam)