20

I use pthread_create to create several child threads. At a time, the main thread wants to kill all child threads or there will be segment falut. Which function should I use to finish that? I searched the answer from google and got function like pthread_kill. But I did not know which signal should I send to the child thread to kill them. My running environment is RHEL 5.4 and programming language is C.

terry
  • 1,437
  • 4
  • 14
  • 11
  • 2
    wow, kill all thread because there will be a segfault? are you kidding? I'd never by a bit of code that is handled like that. – Jens Gustedt Sep 29 '10 at 14:58
  • 1
    Truely speaking, I gdb the core dump found when the main thread exit global objects were deconstructed. So some child threads may currently use such a variable and segment fault is printed on my screen. Although, the logic is right and segment fault will not have any effects on my program because it is finished. – terry Oct 01 '10 at 08:50
  • 2
    Fix the logic. If the other threads are still doing useful work, why are you trying to terminate the program? If the other threads still need these objects even when `main` goes out of scope, why are they allocated on `main`s stack? – David Schwartz Aug 30 '11 at 13:08

4 Answers4

29

In general, you don't really want to violently kill a child thread, but instead you want to ask it to terminate. That way you can be sure that the child is quitting at a safe spot and all its resources are cleaned up.

I generally do this with a small piece of shared state between parent and child to allow the parent to communicate a "quit request" to each child. This can just be a boolean value for each child, protected by a mutex. The child checks this value periodically (every loop iteration, or whatever convenient checkpoints you have in your child thread). Upon seeing "quit_request" being true, the child thread cleans up and calls pthread_exit.

On the parent side, the "kill_child" routine looks something like this: 

acquire shared mutex
set quit_request to true 
pthread_join the child

The pthread_join may take some time, depending on how frequently the child checks its quit request. Make sure your design can handle whatever the delay may be.

Bill Gribble
  • 1,797
  • 12
  • 15
  • While it's generally good practise to acquire a mutex before modifying any memory that is shared between threads, the fact that this is a single flag that is getting checked for non-zero (or false) status, means that you don't really need to grab a mutex. In this case, there really isn't much that can go wrong from a data coherency perspective. – Bernie Habermeier Jul 26 '13 at 19:51
  • 2
    @Brent: [This question](http://stackoverflow.com/questions/21183261/is-a-race-condition-possible-when-only-one-thread-writes-to-a-bool-variable-in-c) shows an example where even a single flag written once can lead to a race condition after complier optimisations. – dshepherd May 30 '15 at 15:27
  • What happens if the child thread terminates before the call to `pthread_join`? Doesn't the thread need to be guaranteed to be alive when it is joined? – Benjamin Crawford Ctrl-Alt-Tut Oct 20 '19 at 14:53
22

It is possible to "cancel" a thread using pthread_cancel. However, this isn't typically best practice though under extreme circumstances like a SEGFAULT it may be conisdered a reasonable approach.

Community
  • 1
  • 1
torak
  • 5,684
  • 21
  • 25
  • 5
    Why is `pthread_cancel` not considered best practice? And if it is not best practice, what is? – darnir Aug 06 '16 at 21:55
  • @darnir pthread_cancel would be like Ctrl-C, it works and has it's place but shouldn't be the "normal" way to exit your program. A graceful exit where you free your resources, save your files, etc is better. For threads it is better to send a flag to the child and have it quit on it's own. – Paul Hutchinson Sep 13 '22 at 15:34
8

You should send SIG_TERM to each of your threads, using

  int pthread_kill(pthread_t thread, int sig);

A quick way to get rid of all threads (besides the main) is to fork() and keep going with the child.
Not hyper clean...

  if (fork()) exit(0); // deals also with -1...
Déjà vu
  • 28,223
  • 6
  • 72
  • 100
3

You can use a global variable for the entire program.

int _fCloseThreads;

Set it to 1 when you want the threads to quit execution. Have the threads check that variable in their "loop" and nicely quit when it is set to 1. No need to protect it with a mutex.

You need to wait for the threads to quit. You can use join. Another way is to increment a counter when a thread enters its thread proc and then decriment the counter when it exits. The counter would need to be a global of sorts. Use gcc atomic ops on the counter. The main thread, after setting fCloseThreads, can wait on the counter to go to zero by looping, sleeping, and checking the count.

Finally, you might checkout pthread_cleanup_push and pop. They are a model for allowing a thread to cancel anywhere in its code (uses a longjump) and then call a final cleanup function before exiting threadproc. You basicly put cleanup_push at the top of your threadproc and cleanup_pop at the bottom, create an unwind function, and then at certain cancelation points a thread canceled by a call to pthread_cancel() will longjump back to threadproc and call the unwind function.

johnnycrash
  • 5,184
  • 5
  • 34
  • 58