public inbox for pthreads-win32@sourceware.org
 help / color / mirror / Atom feed
* RE: pthread_cond_destroy and cancel
@ 2006-06-13 14:03 Bossom, John
  0 siblings, 0 replies; 3+ messages in thread
From: Bossom, John @ 2006-06-13 14:03 UTC (permalink / raw)
  To: Romano Paolo Tenca, Pthreads-Win32 list

I agree that pthread_cond_destroy is not be a cancellation point. It is
not documented as such in the standard.

The fact that it is (now) implemented with a sem_wait, is an
implementation detail that should be isolated from the caller. I would
consider this to be a bug.


Cheers,

John E. Bossom
(still lurking)

-----Original Message-----
From: pthreads-win32-owner@sourceware.org
[mailto:pthreads-win32-owner@sourceware.org] On Behalf Of Romano Paolo
Tenca
Sent: Tuesday, June 13, 2006 6:26 AM
To: Pthreads-Win32 list
Subject: Re: pthread_cond_destroy and cancel

The problem with the code is that pthread_cond_destroy() is a
cancellation point, because it can call sem_wait().

A weak workaround is to call
    pthread_setcancelstate(PTHREAD_CANCEL_DISABLE,NULL);
before pthread_cond_destroy()

BTW, pthread_cond_destroy is not in the list of cancellation points
(pthread_cancel.html).

I think that a destroy function should not be a cancellation point, else
cleanup routine can easy deadlock itself.

--
Romano Paolo Tenca
 
     This message may contain privileged and/or confidential information.  If you have received this e-mail in error or are not the intended recipient, you may not use, copy, disseminate or distribute it; do not open any attachments, delete it immediately from your system and notify the sender promptly by e-mail that you have done so.  Thank you.

^ permalink raw reply	[flat|nested] 3+ messages in thread

* Re: pthread_cond_destroy and cancel
  2006-06-12 12:27 Romano Paolo Tenca
@ 2006-06-13 10:25 ` Romano Paolo Tenca
  0 siblings, 0 replies; 3+ messages in thread
From: Romano Paolo Tenca @ 2006-06-13 10:25 UTC (permalink / raw)
  To: Pthreads-Win32 list

The problem with the code is that pthread_cond_destroy() is a 
cancellation point, because it can call sem_wait().

A weak workaround is to call
    pthread_setcancelstate(PTHREAD_CANCEL_DISABLE,NULL);
before pthread_cond_destroy()

BTW, pthread_cond_destroy is not in the list of cancellation points 
(pthread_cancel.html).

I think that a destroy function should not be a cancellation point, else 
cleanup routine can easy deadlock itself.

-- 
Romano Paolo Tenca

^ permalink raw reply	[flat|nested] 3+ messages in thread

* pthread_cond_destroy and cancel
@ 2006-06-12 12:27 Romano Paolo Tenca
  2006-06-13 10:25 ` Romano Paolo Tenca
  0 siblings, 1 reply; 3+ messages in thread
From: Romano Paolo Tenca @ 2006-06-12 12:27 UTC (permalink / raw)
  To: Pthreads-Win32 list


This code creates a thread and use 2 cond var to sincronize.

Then the thread is cancelled and the thread hangs executing 
pthread_cond_destroy(&cv2).

The output is
  main: sleeping forever
  thread: try to destroy cv2

Where is the problem? In my code or in pthread_cond_destroy with a 
deferred cancel pending?

----------------------------start of code --------------------------
#include <windows.h>
#include <stdio.h>
#include <pthread.h>
#include <assert.h>

/*
 * compiled with gcc version 3.2.3 (mingw special 20030504-1)
 * under XP Professional
 * linked with libpthreadGC2 2.7.0 prebuilt
 */
static pthread_cond_t cv1 =
    PTHREAD_COND_INITIALIZER;
static pthread_mutex_t mutex1 =
    PTHREAD_ERRORCHECK_MUTEX_INITIALIZER;
static pthread_cond_t cv2 =
    PTHREAD_COND_INITIALIZER;
static pthread_mutex_t mutex2 =
    PTHREAD_ERRORCHECK_MUTEX_INITIALIZER;

static void *func(void *arg){
    int err;
    // signal cv1
    pthread_mutex_lock(&mutex1);
    pthread_cond_signal(&cv1);
    pthread_mutex_lock(&mutex2);
    pthread_mutex_unlock(&mutex1);
    // wait cv2
    pthread_cond_wait(&cv2, &mutex2);
    pthread_mutex_unlock(&mutex2);
    // to be sure that main calls cancel on this thread
    Sleep(50);
    //destroy mutex2 and cv2
    printf("thread: try to destroy cv2\n");
    err = pthread_cond_destroy(&cv2);
    printf("thread: cv2 err: %d\n",err); // bug? this is not executed
    pthread_mutex_destroy(&mutex2);
    return NULL;
}

void test(void){
    int err;
    pthread_t pid;
    pthread_mutex_lock(&mutex1);
    // create thread
    pthread_create(&pid, NULL, func, NULL);
    // wait cv1
    pthread_cond_wait(&cv1, &mutex1);
    pthread_mutex_lock(&mutex2);
    pthread_mutex_unlock(&mutex1);
    // signal cv2
    pthread_cond_signal(&cv2);
    pthread_mutex_unlock(&mutex2);
    //cancel the thread
    err = pthread_cancel(pid);
    assert(err == 0);
    puts("main: sleeping forever");
    Sleep(INFINITE);
}

int main(int argc, char **argv) {
    test();
    return 0;
}

-- 
Romano Paolo Tenca

^ permalink raw reply	[flat|nested] 3+ messages in thread

end of thread, other threads:[~2006-06-13 14:03 UTC | newest]

Thread overview: 3+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2006-06-13 14:03 pthread_cond_destroy and cancel Bossom, John
  -- strict thread matches above, loose matches on Subject: below --
2006-06-12 12:27 Romano Paolo Tenca
2006-06-13 10:25 ` Romano Paolo Tenca

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).