Home ›

Thread-Specific Data and Signal Handling in Multi-Threaded Applications

Issue 36

From Issue #36
April 1997

Apr 01, 1997  By Martin McCarthy
 in
Here are the answers to questions about signal handling and taking care of global data when writing multi-threaded programs.
Differences in Signal Handling between POSIX Threads and LinuxThreads

Listing 4 shows how to deal with signals in a multi-threading environment that handles threads in a POSIX compliant way.

Personally, I like the kernel-level package “LinuxThreads” that makes use of Linux 2.0's clone() system call to create new threads. At some point in the future, the clone() call may implement the CLONE_PID flag which would allow all the threads to share a process ID. Until then each thread created using “LinuxThreads” (or any other packages which chooses to use clone() to create threads) will have its own unique process ID. As such, there is no concept of sending a signal to “the process.” If one thread calls sigwait() and all other threads block signals, only those signals which are specifically sent to the sigwait()-ing thread will be processed. Depending on your application, this could mean that you have no choice other than to include an asynchronous signal handler in each of the threads.

Summary

Thread specific data is easy to use—far easier than many people's first experiences may suggest. In a way, this ease of use is a disadvantage, since very often there are more elegant solutions to a problem. But in times of need, thread specific data is your friend.

On the other hand, signal handling in anger can be a little hairy. Anyone who thinks otherwise has overlooked something—either that or they're far too clever for their own good. Make life easier for yourself by consigning all the handling of asynchronous signals to one thread that sits on sigwait().

Martin McCarthy discovered multi-threaded programming while writing the server for a high-speed, multi-user, distributed, virtual-reality system. Of course, he only took that job so that he could squeeze as many buzzwords into his job description as possible. He can be reached at marty@ehabitat.demon.co.uk.

______________________

Comments

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.

SIGALRM - sync or async?

MarkBerg's picture
Submitted by MarkBerg (not verified) on Wed, 07/28/2010 - 10:34.

Is SIGALRM synchronous or async?
i.e. if I use alarm() within a thread, is this thread guaranteed to get the signal, or might some other thread get it?

Listing 4 Contains A Race Condition

Oldfield's picture
Submitted by Oldfield (not verified) on Wed, 08/12/2009 - 21:50.

Do not rely on this method of deliving signal information to threads.

A race occurs if two or more signals arrive in similar timeframes - there is nothing to prevent "handled_signal" from being overwritten prior to another thread being scheduled and told about the first delivered signal.

Bad advice from the journal!

regarding synchronous signals

sravan's picture
Submitted by sravan (not verified) on Wed, 04/22/2009 - 06:47.

hi,

In the Listing 4 code, the signal handler captures only the asynchronous signals(like SIGINT) but not synchronous signals like (SIGFPE,SIGSEGV etc.).

How can i make sure that the dedicated thread does the job of capturing both types of signals?

Thank you

catching SIGFPE and SIGSEGV

Anonymous's picture
Submitted by Anonymous on Sun, 02/14/2010 - 07:18.

signals SIGSTOP and SIGSEGV cannot be caught or ignored. I am not sure about SIGFPE....according to POSIX ignoring SIGFPE results in undefined behavior....I have tried to catch SIGFPE on my Linux system...but programme terminated with "Floating point exception"

SIGSEGV and SIGFPE can certainly be caught

Darren Kulp's picture
Submitted by Darren Kulp (not verified) on Tue, 08/17/2010 - 08:47.

SIGSEGV and SIGFPE can certainly be caught; in fact, I have intentionally generated and caught both in the same program, to sandbox pseudo-simulated code. The SIGSEGV signal is thrown not only when a "truly invalid" memory access is made, but when permissions are incorrect on the desired page; it is possible to change the permissions on the page from within the handler, and return to the original code (this is what my handler did).

From the sigaction man page:

signum specifies the signal and can be any valid signal except SIGKILL and SIGSTOP.

Thread safety

C2H5OH's picture
Submitted by C2H5OH (not verified) on Fri, 06/13/2008 - 07:59.

Regarding Listing 3. I believe not all malloc() implementations are thread-safe (in fact, very few of them actually are); so I'll assume that calling malloc inside a thread without a mutex is a typo.

My real question is. The key destructor in pthread_key_create(), from where is it called? The main thread or the same thread that is terminating? Is not clear anywhere. Perhaps I should check the POSIX specification but it is also difficult to find.

Cheers

Re: Thread safety

Anonymous's picture
Submitted by Anonymous (not verified) on Wed, 01/07/2009 - 03:35.

That is totally bogus. Any _sane_ environment that supports threads also has thread-safe malloc() and other primitives.

Thanks a million ...

Anonymous's picture
Submitted by Anonymous (not verified) on Fri, 10/12/2007 - 09:40.

... for posting this article

Cheers !

Re: Thread-Specific Data and Signal Handling in Multi-Threaded A

Anonymous's picture
Submitted by Anonymous on Tue, 06/04/2002 - 02:00.

can anybody give an example code on how to make "errno" as thread specific data.

thanks in advance

rksoni@indts.com

errno should be automatically

Anonymous's picture
Submitted by Anonymous (not verified) on Thu, 04/14/2005 - 11:29.

errno should be automatically thread specific, if you compile and link with the right flags (if required by your compiler). You shouldn't have to do anything special to make it thread specific.

Getting good info on pthreads, sockets, signals

Anonymous's picture
Submitted by Anonymous (not verified) on Wed, 09/12/2007 - 07:37.

Unix Systems Programming (Communication, Concurrency and Threads)
by Robbins & Robbins [Pearson Education]

It has got a good coverage of all the related areas on sockets, threads and signals all in one place. Very good book.

White Paper
More Resources
Fabric-Based Computing Enables Optimized Hyperscale Data Centers

Today’s modular x86 servers are compute-centric, designed as a least common denominator to support a wide range of IT workloads. Those generic, virtualized IT workloads have much different resource optimization requirements than hyperscale and cloud applications. They have resulted in a “one size fits all” enterprise IT architecture that is not optimized for a specific set of IT workloads, and especially not emerging hyperscale workloads, such as web applications, big data, and object storage. In this report, you will learn how shifting the focus from traditional compute-centric IT architectures to an innovative disaggregated fabric-based architecture can optimize and scale your data center.

Learn More

Sponsored by AMD

White Paper
More Resources
Red Hat White Paper: Using an Open Source Framework to Catch the Bad Guy

Built-in forensics, incident response, and security with Red Hat Enterprise Linux 6

Every security policy provides guidance and requirements for ensuring adequate protection of information and data, as well as high-level technical and administrative security requirements for a system in a given environment. Traditionally, providing security for a system focuses on the confidentiality of the information on it. However, protecting the data integrity and system and data availability is just as important. For example, when processing United States intelligence information, there are three attributes that require protection: confidentiality, integrity, and availability.

Learn more about catching the bad guy in this free white paper.

Learn More

Sponsored by DLT Solutions