Printable View
Well It is me again asking about threads hehehehe :D
This time im interested in timers and threads. I've read about signals and I understand pretty much everything except pthread_sigmask() why is this function important when implementing timers with signals and alarm(). I am a bit lost with pthread_sigmask() Help
Thanks in advance
pthread_sigmask() is a thread-safe version of sigprocmask(). You also shouldn't use signal() in a mutli-threaded app. Use sigaction() instead.
gg
POSIX places a lot of restrictions on signals in multithreaded applications. For instance, the exact thread which receives a particular signal is undefined by the standard. In order to control signal delivery, only a single thread may unmask the desired signal, and it must remain masked in all other threads.Quote:
Originally Posted by scioner
On Linux, a thread and a process are basically the same thing, but on many UNIX systems they are not. On some systems, all signals might be intercepted by the pthreads library and dispatched through user space. In general you can't know for sure how exactly this dispatch operation happens. So to avoid mistakes, pthreads requires you to configure signals through pthreads-specific methods instead of the system's native methods.
so basically threads and signals are a pain is there any other method to implement a timer I don't want to use select() or poll() I tried to use another thread but that does not go well with my design because of the mutexes and global variables.
so any advice?
It's not that bad. Use the example code in the following link as a template:
http://www.opengroup.org/onlinepubs/...d_sigmask.html
gg
All you have to do is use pthread_sigmask() to mask all signals in every thread you create. In other words, the first thing you do in every thread function is call pthread_sigmask() to mask everything. In the single thread where you want the timer signal to be delivered, call pthread_sigmask() again to unmask the signal and everything will be okay.Quote:
Originally Posted by scioner
But I'm kind of wondering why you're using a signal to implement a timer in a multithreaded application. Why not just have a timer thread that sleeps for the required duration? When it wakes up, it can indicate this to the rest of the program with a pthread_cond_broadcast().
>> In the single thread where you want the timer signal to be delivered, call pthread_sigmask() again to unmask the signal ...
Well, the only way I know for one of your threads to handle a signal in its own context is to block that signal on all threads, then poll for the signal using sigwait(), sigtimedwait(), or sigwaitinfo(). This avoids some of the restrictions of what you can and can't do inside a signal handler.
>> Why not just have a timer thread that sleeps for the required duration?
That's certainly doable. I suppose using signal based timers makes sense if you've got other signals that could also be handled in the thread - or if you have multiple timers.
gg
Doesnt threads inherit the signal masks? can I mask all the signals before creating a thread and then inside the thread unblock the alarma signal?Quote:
ll you have to do is use pthread_sigmask() to mask all signals in every thread you create. In other words, the first thing you do in every thread function is call pthread_sigmask() to mask everything.
About using pthread_cond_broadcast() that would certainly be a choice I just want to use signals see how it goes first to learn a little bit more about them
>> Doesnt threads inherit the signal masks? can I mask all the signals before creating a thread and then inside the thread unblock the alarma signal?
Yes. But you leave any signals you want your thread to handle blocked (like in the example code). That way when the signal occurs, it will stay pending until "delivered" by sigwait().
gg