POSIX: Difference between revisions

From miki
Jump to navigation Jump to search
Line 77: Line 77:
=== Debugging ===
=== Debugging ===
See [[Debugging]] page.
See [[Debugging]] page.

== Signals ==

Manual pages:
* [http://localhost/cgi-bin/dwww?type=runman&location=signal/7 signal(7)]

=== Async-Signal Safety ===
''Async-signal safety'' is similar to thread safety. Since asynchronous signals (like SIGINT or SIGIO) may happen anytime, and this interrupt any function, it might not be same to call the interrupted function again (concurrently) from with the signal handler. POSIX defines the set of system functions that are ''async-signal safe'' (see [http://localhost/cgi-bin/dwww?type=runman&location=signal/7 signal(7)]).


Note that pthread functions are '''not''' in the list, so it is not quite clear how to wake up another suspended thread from within an async-signal handler.

Some ideas:
* Use ''signals'' to wake up the suspended thread. This assumes that the suspended thread is waiting on signals (see [http://localhost/cgi-bin/dwww?type=runman&location=sigtimedwait/2 sigtimedwait(2)], [http://localhost/cgi-bin/dwww?type=runman&location=sigtimedwait/3posix sigtimedwait(3)]).
* Calling <code>pthread_cond_signal</code> is unsafe from signal handler (see [http://localhost/cgi-bin/dwww?type=runman&location=pthread%5fcond%5fwait/3]), because handler thread may dead-lock if it interrupts a ''[http://localhost/cgi-bin/dwww?type=runman&location=pthread%5fcond%5fwait/3 pthread_cond]'' functions (system may use a semaphore internally). Maybe is it possible to suspend the processing of async-signal before so that they do not interrupt these critical sections? (see for instance [http://localhost/cgi-bin/dwww?type=runman&location=sigsuspend/3posix sigsuspend(3posix)]).
* Use [http://localhost/cgi-bin/dwww?type=runman&location=sem_post/3posix sem_post(3posix)]. This function is async-signal safe. The idea would be to have a separate thread that is just waiting on a semaphore, and which is waken up by the signal handler using <code>sem_post</code>. The cost of an additional thread seems a bit heavy weight.

=== Some interesting read ===
; [http://elliotth.blogspot.be/2011/05/signal2-versus-sigaction2.html signal(2) versus sigaction(2)]
: Some ideas on how to have multiple threads blocking on I/O and being able to cancel them.

Revision as of 23:51, 3 November 2012

PThreads

General Information

Links:

Manual page:

Portability

Joinable / detachable state
For portability, always create joinable or detachable threads by setting explicitly the thread attribute (using pthread_attr_getdetachstate). This provides portability as not all implementations may create threads as joinable by default.

Linux vs. POSIX manual pages

Most manual pages on pthreads are available as either standard linux manual pages or as extract from the POSIX programmer manual.

For instance:

Both versions are worth reading.

Create threads

See pthread_create(3).

Conditional variables

See

  • pthread_cond_init
  • pthread_cond_destroy
  • pthread_cond_signal
  • pthread_cond_broadcast
  • pthread_cond_wait
  • pthread_cond_timedwait

Note that these functions are NOT signal-async safe (see [1], [2]). They CANNOT be called safely from a async signal handler (like SIGIO signal handler).

Thread-Local Data

// Compile this code with : gcc local.c -o local -lpthread

#include <stdio.h>
#include <unistd.h>
#include <pthread.h>

static __thread int myint;
static int globalint = 0;

void * handler(void *arg)
{
    myint = ++globalint;                              // thread unsafe - should use a mutex
    while(1) {
        printf("myint is %d\n", myint);
        sleep(1);
    }
}

int main (int argc, char **argv)
{
    pthread_t p1,p2;

    pthread_create(&p1, NULL, handler, NULL);
    pthread_create(&p2, NULL, handler, NULL);

    pause();
    return 0;
}

Debugging

See Debugging page.

Signals

Manual pages:

Async-Signal Safety

Async-signal safety is similar to thread safety. Since asynchronous signals (like SIGINT or SIGIO) may happen anytime, and this interrupt any function, it might not be same to call the interrupted function again (concurrently) from with the signal handler. POSIX defines the set of system functions that are async-signal safe (see signal(7)).


Note that pthread functions are not in the list, so it is not quite clear how to wake up another suspended thread from within an async-signal handler.

Some ideas:

  • Use signals to wake up the suspended thread. This assumes that the suspended thread is waiting on signals (see sigtimedwait(2), sigtimedwait(3)).
  • Calling pthread_cond_signal is unsafe from signal handler (see [4]), because handler thread may dead-lock if it interrupts a pthread_cond functions (system may use a semaphore internally). Maybe is it possible to suspend the processing of async-signal before so that they do not interrupt these critical sections? (see for instance sigsuspend(3posix)).
  • Use sem_post(3posix). This function is async-signal safe. The idea would be to have a separate thread that is just waiting on a semaphore, and which is waken up by the signal handler using sem_post. The cost of an additional thread seems a bit heavy weight.

Some interesting read

signal(2) versus sigaction(2)
Some ideas on how to have multiple threads blocking on I/O and being able to cancel them.