5

In my program, to create a barrier, the main thread sends signals to all the other threads. Now, I want to check if the thread which is executing the signal handler had a mutex locked when the signal handler started. Is there any way to check that inside the signal handler?

MetallicPriest
  • 29,191
  • 52
  • 200
  • 356
  • 1
    From what I've read, doing much of anything inside a signal handler beyond setting a flag or the like is dangerous. – C. K. Young Jul 05 '11 at 15:20

1 Answers1

5

Reading through your comments, it appears as though your program is a lot more complex than I thought. If you have 1000's of mutexes, checking to see if they are locked in a signal handler is a bad idea. In fact, if your app is this highly threaded, mixing signals and threads is also an idea I think you should reconsider. The reason for this is mainly inherent in the fact that you can't set a status flag and lock a mutex in an atomic fashion that would be signal-safe. In order to create the proper conditions to support updating a status entry for your mutex, as well as locking the mutex without being interrupted by a signal in the process, you're going to have to create a bunch of code to wrap all your mutex-locking and unlocking functions in critical sections that block any signals the thread could receive, so that you can both lock/unlock a given mutex, as well as set/unset a flag for the mutex's state that can then be read in the signal handler.

A better solution would be to have only a single thread accept signals, with all the other threads blocking the signals you're sending, including the main thread. Then, rather than having to send signals to individual threads, you can simply send signals to the entire process. Upon sending the signal, the only thread that is set for receiving signals and handling them waits with a call to sigwait() for the appropriate signal, and upon receipt, quickly checks an array of values to see which mutexes are set, and which specific thread owns them. For this information your array can be an array of values that are a structure type containing a pointer to the mutex, a locked/unlocked flag, as well as a pointer to the pthread_t of the thread that you can use to get the thread ID value from. For instance, you struct could look something like:

typedef struct mutex_info
{
    pthread_mutex_t* mutex_handle;
    pthread_t* thread_handle;
    int locked;
} mutex_info;

mutex_info mutex_info_array[NUM_MUTEXES];

Then your other threads, without having to worry about asynchronous signal events, can simply update the array values every time they lock or unlock a specific mutex.

Jason
  • 31,834
  • 7
  • 59
  • 78
  • With pthread_mutex_trylock(), I need to pass the mutex as a parameter. Now this is not good, because say my program has 1000s of mutexes, I'm not gonna call pthread_mutex_trylock() 1000s of times to check for each mutex. Isn't there any way to know which mutexes if any are locked by the thread who is processing the signal handler, without checking for each of them? – MetallicPriest Jul 05 '11 at 15:54
  • 1
    One way which comes in my mind is to log the information that a mutex is locked in some queue and read that queue in the signal handler. Obviously I would need to create a wrapper function for that, which not only locks a mutex but also logs this info. – MetallicPriest Jul 05 '11 at 16:00
  • 2
    "You can call pthread_mutex_trylock() in the signal-handler" - not really, since it's not on the list of async-signal-safe functions. – Steve Jessop Jul 05 '11 at 16:01
  • 1
    There are at least two things wrong with this answer... First, [`pthread_mutex_trylock`](http://pubs.opengroup.org/onlinepubs/9699919799/functions/pthread_mutex_trylock.html) only gives `EDEADLK` for "error checking" mutexes. Second, as @Steve points out, pthread functions are generally not on the list of [async-signal-safe functions](http://pubs.opengroup.org/onlinepubs/9699919799/functions/V2_chap02.html#tag_15_04_03). – Nemo Jul 05 '11 at 17:34
  • Okay, I've updated my answer based on the responses. Please let me know if this solution works better ... Also @Nemo, thanks for the tip ... I now see that if the mutex type is `PTHREAD_MUTEX_NORMAL`, that a deadlock will ensue, which is a very bad idea. – Jason Jul 05 '11 at 17:51
  • Much better answer. +1. – Nemo Jul 05 '11 at 18:17