pthread_cond_timedwait and signal handler - Unix

This is a discussion on pthread_cond_timedwait and signal handler - Unix ; Hello all, I have a program with several threads. In the main thread, I use pthread_cond_timedwait() to wait for a condition from another thread or a timeout expiration. However I would like to cancel waiting also via user interaction. I ...

+ Reply to Thread
Results 1 to 2 of 2

Thread: pthread_cond_timedwait and signal handler

  1. pthread_cond_timedwait and signal handler

    Hello all,

    I have a program with several threads.

    In the main thread, I use pthread_cond_timedwait() to wait for a condition
    from another thread or a timeout expiration.

    However I would like to cancel waiting also via user interaction. I have a
    signal handler for it on SIGINT (Ctrl-C).

    My question is what is the safe way to interrupt pthread_cond_timedwait()
    from within signal handler from the same thread.
    I've read that calling pthread_mutex_lock() of pthread_cond_signal() is not
    safe from within signal handler.

    My only idea is to use pthread_mutex_trylock() in signal handler and in
    another thread check its usage via pthread_mutex_trylock() and then use
    pthread_cond_signal() to signal condition to the main thread.
    But it looks quite complicated and not very elegant.

    Does anybody have a better idea?

    Thank in advance,
    Jirka


  2. Re: pthread_cond_timedwait and signal handler

    On Nov 30, 1:13 pm, Jiri Klimes wrote:
    > Hello all,
    >
    > I have a program with several threads.
    >
    > In the main thread, I use pthread_cond_timedwait() to wait for a condition
    > from another thread or a timeout expiration.
    >
    > However I would like to cancel waiting also via user interaction. I have a
    > signal handler for it on SIGINT (Ctrl-C).
    >
    > My question is what is the safe way to interrupt pthread_cond_timedwait()
    > from within signal handler from the same thread.
    > I've read that calling pthread_mutex_lock() of pthread_cond_signal() is not
    > safe from within signal handler.


    yeah, bad idea! You likely end up with some deadlock or worse!
    pthreads and signals really do not mix very well. IIRC DECThreads had
    some pthread_np (non-portable) stuff that was async signal safe, but
    there's no such thing in POSIX

    IMHO, the only reasonable way to deal with signals in pthreads is to
    block all "interresting" signals in main(), then to spawn a dedicated
    "signal handling thread" that sits and loops on
    sigwait translating signals into business code:

    int interrupted = 0; // somehow global state, or passed through to
    thread func

    sigset_t signal_set; // also shared

    void*
    signal_handling(void* /*arg*/)
    {
    int sig;
    while( 1 ) {
    sigwait( &signal_set, &sig );
    if( SIGINT == sig ) { // trigger shutdown or whatever
    pthread_mutex_lock( &mutex );
    interrupted = 1;
    pthread_cond_signal( &cond );
    pthread_mutex_unlock( &mutex );

    } else {
    // other
    }
    }
    return 0;
    }

    int
    main()
    {
    sigemptyset( &signal_set );
    sigaddset( &signal_set, SIGINT );
    // ... other
    pthread_sigmask( SIG_BLOCK, &signal_set, 0 );

    // spawn signal handling thread, signal_set is inherited

    pthread_create( &signal_handler_id, 0, &signal_handling_thread,
    0 );

    // launch some worker threads

    // pthread_cond_timedwait on cond
    }

    >
    > My only idea is to use pthread_mutex_trylock() in signal handler and in
    > another thread check its usage via pthread_mutex_trylock() and then use
    > pthread_cond_signal() to signal condition to the main thread.


    no, don't! try with above

    Christoph

+ Reply to Thread