I don't need to terminate the thread correctly, or make it respond to a "terminate" command. I am interested in terminating the thread forcefully using pure C++11.

- 347,512
- 102
- 1,199
- 985

- 8,351
- 4
- 38
- 47
-
7Here is good question on this topic: http://stackoverflow.com/questions/2790346/c0x-thread-interruption "All the language specification says that the support isn't built into the language" – Nemanja Boric Aug 31 '12 at 01:23
7 Answers
You could call
std::terminate()
from any thread and the thread you're referring to will forcefully end.You could arrange for
~thread()
to be executed on the object of the target thread, without a interveningjoin()
nordetach()
on that object. This will have the same effect as option 1.You could design an exception which has a destructor which throws an exception. And then arrange for the target thread to throw this exception when it is to be forcefully terminated. The tricky part on this one is getting the target thread to throw this exception.
Options 1 and 2 don't leak intra-process resources, but they terminate every thread.
Option 3 will probably leak resources, but is partially cooperative in that the target thread has to agree to throw the exception.
There is no portable way in C++11 (that I'm aware of) to non-cooperatively kill a single thread in a multi-thread program (i.e. without killing all threads). There was no motivation to design such a feature.
A std::thread
may have this member function:
native_handle_type native_handle();
You might be able to use this to call an OS-dependent function to do what you want. For example on Apple's OS's, this function exists and native_handle_type
is a pthread_t
. If you are successful, you are likely to leak resources.

- 206,506
- 52
- 449
- 577
-
3Slight nitpick on _"don't leak intra-process resources"_: While it is of course true that the OS will reclaim all resources after killing the process, resources _are_ leaked as far as the program is concerned. That is usually irrelevant, but may still be an issue in some cases. `std::terminate` neither calls static destructors nor does it flush output buffers, so the order in which resources are released isn't well-defined, nor do you have any guarantee that any of your data is visible to the user or written to permanent store, or even consistent and complete. – Damon Feb 19 '15 at 14:04
-
8You can also call `exit()` or `abort()` to the same overall effect. – n. m. could be an AI May 30 '18 at 09:41
-
4#1 is a joke and @ChrisDodd is right. The joke is explained in the answer in the first sentence under #3. Also see Nanno Langstraat's answer and the comments below it. – Howard Hinnant Feb 21 '19 at 17:42
-
2
-
3Yes. Options 1 and 2 don't leak intra-process resources, but they terminate *every* thread. Somehow it is not as funny when you have to explain the joke... ;-) – Howard Hinnant Jan 10 '22 at 20:51
@Howard Hinnant's answer is both correct and comprehensive. But it might be misunderstood if it's read too quickly, because std::terminate()
(whole process) happens to have the same name as the "terminating" that @Alexander V had in mind (1 thread).
Summary: "terminate 1 thread + forcefully (target thread doesn't cooperate) + pure C++11 = No way."

- 4,122
- 4
- 47
- 81

- 1,335
- 10
- 8
-
25Ahh, my #1 is truly funny. You don't have to specify which thread you want to forcefully end. The system just magically knows which one you want to forcefully end and does it! – Howard Hinnant Dec 12 '13 at 15:31
-
20Yes, the `std::terminate()` answer is like a classic mischievous Djinn story; it fulfills everything in the OP's wish to the letter, though probably not in the way he *meant*. The understated humor made me smile. :-) – Nanno Langstraat Jan 02 '14 at 01:00
-
4Just have to prevent innocent C++ novices from getting their hopes up too far / too long. – Nanno Langstraat Jan 02 '14 at 01:01
I guess the thread that needs to be killed is either in any kind of waiting mode, or doing some heavy job. I would suggest using a "naive" way.
Define some global boolean:
std::atomic_bool stop_thread_1 = false;
Put the following code (or similar) in several key points, in a way that it will cause all functions in the call stack to return until the thread naturally ends:
if (stop_thread_1)
return;
Then to stop the thread from another (main) thread:
stop_thread_1 = true;
thread1.join ();
stop_thread_1 = false; //(for next time. this can be when starting the thread instead)

- 443
- 3
- 12
-
4But what about if the thread is performing a busy blocked job like a `curl` command (which takes long to execute or something). And this curl command (read libcurl library) is a blocking call in the thread. I don't have a while loop or something to check for `stop_thread_1`. – Melroy van den Berg Dec 28 '21 at 00:25
-
To answer my own remark. I didn't solve my problem yet, but I think the answer lies in libcurl "multi interface", with the `curl_multi_wakeup` and `curl_multi_poll` calls. – Melroy van den Berg Dec 28 '21 at 00:46
Tips of using OS-dependent function to terminate C++ thread:
std::thread::native_handle()
only can get the thread’s valid native handle type before callingjoin()
ordetach()
. After that,native_handle()
returns 0 -pthread_cancel()
will coredump.To effectively call native thread termination function(e.g.
pthread_cancel()
), you need to save the native handle before callingstd::thread::join()
orstd::thread::detach()
. So that your native terminator always has a valid native handle to use.
More explanations please refer to: http://bo-yang.github.io/2017/11/19/cpp-kill-detached-thread .
-
No no no! That will not work! See here: https://stackoverflow.com/a/72387607 – ajneu Jun 13 '23 at 17:03
This question actually have more deep nature and good understanding of the multithreading concepts in general will provide you insight about this topic. In fact there is no any language or any operating system which provide you facilities for asynchronous abruptly thread termination without warning to not use them. And all these execution environments strongly advise developer or even require build multithreading applications on the base of cooperative or synchronous thread termination. The reason for this common decisions and advices is that all they are built on the base of the same general multithreading model.
Let's compare multiprocessing and multithreading concepts to better understand advantages and limitations of the second one.
Multiprocessing assumes splitting of the entire execution environment into set of completely isolated processes controlled by the operating system. Process incorporates and isolates execution environment state including local memory of the process and data inside it and all system resources like files, sockets, synchronization objects. Isolation is a critically important characteristic of the process, because it limits the faults propagation by the process borders. In other words, no one process can affects the consistency of any another process in the system. The same is true for the process behaviour but in the less restricted and more blur way. In such environment any process can be killed in any "arbitrary" moment, because firstly each process is isolated, secondly, operating system have full knowledges about all resources used by process and can release all of them without leaking, and finally process will be killed by OS not really in arbitrary moment, but in the number of well defined points where the state of the process is well known.
In contrast, multithreading assumes running multiple threads in the same process. But all this threads are share the same isolation box and there is no any operating system control of the internal state of the process. As a result any thread is able to change global process state as well as corrupt it. At the same moment the points in which the state of the thread is well known to be safe to kill a thread completely depends on the application logic and are not known neither for operating system nor for programming language runtime. As a result thread termination at the arbitrary moment means killing it at arbitrary point of its execution path and can easily lead to the process-wide data corruption, memory and handles leakage, threads leakage and spinlocks and other intra-process synchronization primitives leaved in the closed state preventing other threads in doing progress.
Due to this the common approach is to force developers to implement synchronous or cooperative thread termination, where the one thread can request other thread termination and other thread in well-defined point can check this request and start the shutdown procedure from the well-defined state with releasing of all global system-wide resources and local process-wide resources in the safe and consistent way.

- 3,434
- 32
- 28
-
9This isn't a very helpful answer. Multi-processing isn't relevant here, and the observations about multi-threading are rather broad. – MSalters Mar 17 '15 at 14:25
-
5What I wanted to say and said in details is that multithreading model doesn't provide formal way of forceful thread termination. C++ wants to follow the clear models including memory model, multithreading model etc. Method of forceful thread termination is inherently unsafe. If C++ standard committee would be forced to add it to C++, it would be made with next statement "Method terminate() terminates thread execution. Behavior undefined.", which will be sound like "make some magic and (possibly) terminates the thread". – ZarathustrA Mar 18 '15 at 00:20
-
-
1@Derf Skren "In fact there is no any language or any operating system which provide you facilities for asynchronous abruptly thread termination without warning to not use them" (c) ZarathustrA "Remarks: Important! The Thread.Abort method should be used with caution. Particularly when you call it to abort a thread other than the current thread, you do not know what code has executed or failed to execute..." (c) Microsoft link: https://learn.microsoft.com/en-us/dotnet/api/system.threading.thread.abort?view=netcore-3.1 – ZarathustrA Jul 29 '20 at 06:44
-
@DerfSkren Thread.Abort is just as risky in C# as this method is in C++. It's a bit unfortunate that the only reliable way to hedge against a buggy third party function that goes into infinite loops or waits for something that will never come is to start a new process. I don't think that was thought through very well. – jrh Feb 22 '21 at 18:40
-
@jrh it's just as risky or not risky, depending on the situation. Sometimes it's the only option, or the most convenient. I was just pointing out that in any OS it is possible to stop giving a thread CPU time and to deallocate its stack, and it annoys me when we have to sit through a 2 hour lecture on why that's scary and why language designers are oh so wise to prevent us from doing it. – Derf Skren Jul 19 '21 at 22:53
-
Maybe TerminateThread? In windows only.
WINBASEAPI WINBOOL WINAPI TerminateThread (HANDLE hThread, DWORD dwExitCode);

- 164
- 1
- 11
You can't use a C++ std::thread
destructor to terminate a single thread in a multi-threads program. Here's the relevant code snippet of std::thread
destructor, located in the thread
header file (Visual C++):
~thread()
{
if (joinable())
std::terminate();
}
If you call the destructor of a joinable thread, the destructor calls std::terminate() that acts on the process; not on the thread, otherwise, it does nothing.
It is possible to "terminating the thread forcefully" (C++11 std::thread) by using OS function. On Windows, you can use TerminateThread. "TerminateThread
is a dangerous function that should only be used in the most extreme cases." - Microsoft | Learn.
TerminateThread(tr.native_handle(), 1);
In order to TerminateThread
to effect, you should not call join()
/ detach()
before, since such a call will nullify native_handle()
.
You should call detach()
(or join()
) after TerminateThread
. Otherwise, as written on the 1st paragraph, on thread destructor std::terminate()
will be called and the whole process will be terminated.
Example:
#include <iostream>
#include <thread>
#include <Windows.h>
void Work10Seconds()
{
std::cout << "Work10Seconds - entered\n";
for (uint8_t i = 0; i < 20; ++i) {
std::this_thread::sleep_for(std::chrono::milliseconds(500));
std::cout << "Work10Seconds - working\n";
}
std::cout << "Work10Seconds - exited\n";
}
int main() {
std::cout << "main - started\n";
std::thread tr{};
std::cout << "main - Run 10 seconds work thread\n";
tr = std::thread(Work10Seconds);
std::cout << "main - Sleep 2 seconds\n";
std::this_thread::sleep_for(std::chrono::seconds(2));
std::cout << "main - TerminateThread\n";
TerminateThread(tr.native_handle(), 1);
tr.detach(); // After TerminateThread
std::cout << "main - Sleep 2 seconds\n";
std::this_thread::sleep_for(std::chrono::seconds(2));
std::cout << "main - exited\n";
}
Output:
main - started
main - Run 10 seconds work thread
main - Sleep 2 seconds
Work10Seconds - entered
Work10Seconds - working
Work10Seconds - working
Work10Seconds - working
main - TerminateThread
main - Sleep 2 seconds
main - exited

- 645
- 1
- 3
- 19