终止线程c ++ 11在读取时阻塞
Posted
技术标签:
【中文标题】终止线程c ++ 11在读取时阻塞【英文标题】：Terminate thread c++11 blocked on read 【发布时间】：2018-08-08 08:36:31 【问题描述】：我有以下代码：
class Foo
private:
std::thread thread;
void run();
std::atomic_flag running;
std::thread::native_handle_type native;
public:
Foo(const std::string& filename);
virtual ~Foo();
virtual void doOnChange();
void start();
void quit();
;
#include "Foo.h"
#include <functional>
#include <iostream>
Foo::Foo(const std::string& filename) :
thread(), running(ATOMIC_FLAG_INIT)
file = filename;
native = 0;
Foo::~Foo()
quit();
void Foo::start()
running.test_and_set();
try
thread = std::thread(&Foo::run, this);
catch (...)
running.clear();
throw;
native = thread.native_handle();
void Foo::quit()
running.clear();
pthread_cancel(native);
pthread_join(native, nullptr);
//c++11-style not working here
/*if (thread.joinable())
thread.join();
thread.detach();
*/
void Foo::run()
while (running.test_and_set())
numRead = read(fd, buf, BUF_LEN);
.....bla bla bla.......
我试图在我的程序清理代码中退出这个线程。使用 pthread 是可行的，但我想知道我是否可以仅使用 c++11 做一些更好的事情（没有本机句柄）。在我看来，使用 c++11 代码处理所有情况没有好方法。正如您在此处看到的，线程在读取系统调用时被阻塞。因此，即使我清除标志，线程仍将被阻塞，并且加入调用将永远阻塞。所以我真正需要的是一个中断（在这种情况下是pthread_cancel）。但是如果我调用pthread_cancel 我不能再调用c++11 join() 方法，因为它失败了，我只能调用pthread_join()。所以看来标准有一个很大的限制，我错过了什么吗？
编辑：
经过下面的讨论，我更改了 Foo 类实现，将 std::atomic_flag 替换为 std::atomic 并使用信号处理程序。我使用信号处理程序是因为我认为最好有一个通用的基类，在基类中使用自管道技巧太难了，逻辑应该委托给孩子。最终实现：
#include <thread>
#include <atomic>
class Foo
private:
std::thread thread;
void mainFoo();
std::atomic<bool> running;
std::string name;
std::thread::native_handle_type native;
static void signalHandler(int signal);
void run();
public:
Thread(const std::string& name);
virtual ~Thread();
void start();
void quit();
void interrupt();
void join();
void detach();
const std::string& getName() const;
bool isRunning() const;
;
Cpp 文件：
#include <functional>
#include <fcntl.h>
#include <limits.h>
#include <stdio.h>
#include <stdlib.h>
#include <unistd.h>
#include <sys/stat.h>
#include <sys/types.h>
#include <sys/inotify.h>
#include <Foo.h>
#include <csignal>
#include <iostream>
Foo::Foo(const std::string& name) :
name(name)
running = false;
native = 0;
this->name.resize(16, '\0');
Foo::~Foo()
void Foo::start()
running = true;
try
thread = std::thread(&Foo::mainFoo, this);
catch (...)
running = false;
throw;
native = thread.native_handle();
pthread_setname_np(native, name.c_str());
void Foo::quit()
if (running)
running = false;
pthread_kill(native, SIGINT);
if (thread.joinable())
thread.join();
void Foo::mainFoo()
//enforce POSIX semantics
siginterrupt(SIGINT, true);
std::signal(SIGINT, signalHandler);
run();
running = false;
void Foo::join()
if (thread.joinable())
thread.join();
void Foo::signalHandler(int signal)
void Foo::interrupt()
pthread_kill(native, SIGINT);
void Foo::detach()
if (thread.joinable())
thread.detach();
const std::string& Foo::getName() const
return name;
bool Foo::isRunning() const
return running;
void Foo::run()
while(isRunning())
num = read(.....);
//if read is interrupted loop again, this time
//isRunning() will return false
【问题讨论】：
强制“杀死”线程绝不是一个好主意，因为线程将无法释放它可能分配的任何资源。如果您需要能够要求一个线程在它结束之前退出，那么考虑使用例如非阻塞 I/O 或类似的。 在某些平台（MS Windows）中，终止线程会使您的应用程序处于不稳定状态。这由 MS 记录。简单示例：线程在终止时持有（内部）C++ 堆锁——现在你没有堆了。 @Some 程序员老兄实际上可以使用 pthread 调用清理处理程序，在我的示例中不是，但可能 还是不够。让我们以这个假设的情况为例：您使用new 在线程中的循环中分配对象。分配已成功，但尚未完成对指针的分配。然后线程被杀死，并且您泄漏对象（更不用说如果指针未初始化可能的UB）。除非您可以同步线程并杀死它，否则总会有泄漏和 UB 的机会。而且如果可以同步杀掉线程，为什么要一开始就强杀而不是让它自己清理呢？
不要屏蔽。查看“readsome”、“in_avail”和相关函数。
【参考方案1】：
正如您在此处看到的，线程在读取系统调用时被阻塞。因此，即使我清除了标志，线程仍将被阻塞，并且 join 调用将永远阻塞。
对此的解决方案是std::raise 一个信号，例如SIGINT 编辑：您需要使用pthread_kill 提高信号，以便信号将由正确的线程处理。正如您从手册中看到的那样，read 被信号中断。您必须处理std::signal，否则整个进程将提前终止。
在使用 BSD 信号处理而不是 POSIX 的系统上，系统调用默认重新启动，而不是在中断时失败。我建议的方法依赖于 POSIX 行为，其中调用设置 EINTR 并返回。 POSIX 行为可以使用siginterrupt 显式设置。另一种选择是使用sigaction 注册信号处理程序，除非由标志指定，否则不会重新启动。
read被中断后，在重读之前必须检查线程是否应该停止。
使用 c++11（甚至可能没有它）不要在线程中调用任何阻塞系统调用
调用阻塞系统调用就可以了。如果您希望在不终止进程的情况下（在有限时间内）终止线程，则不应调用 uninterruptible 系统调用，这些调用可能会无限期长时间地阻塞。在我的脑海中，我不知道是否有任何系统调用符合这样的描述。
一个最小的例子（除了无限期阻塞read之外，你可以使用sleep(100000)来模拟它）：
#include <thread>
#include <iostream>
#include <csignal>
#include <cerrno>
#include <unistd.h>
constexpr int quit_signal = SIGINT;
thread_local volatile std::sig_atomic_t quit = false;
int main()
// enforce POSIX semantics
siginterrupt(quit_signal, true);
// register signal handler
std::signal(quit_signal, [](int)
quit = true;
);
auto t = std::thread([]()
char buf[10];
while(!quit)
std::cout << "initiated read\n";
int count = read(some_fd_that_never_finishes, buf, sizeof buf);
if (count == -1)
if (errno == EINTR)
std::cout << "read was interrupted due to a signal.\n";
continue;
std::cout << "quit is true. Exiting\n";;
);
// wait for a while and let the child thread initiate read
sleep(1);
// send signal to thread
pthread_kill(t.native_handle(), quit_signal);
t.join();
强行杀死一个线程通常是一个非常糟糕的主意，尤其是在 C++ 中，这可能是std::thread API 不为其提供接口的原因。
如果你真的想杀死一个执行线程——在这种情况下这不是必需的，因为你可以安全地中断系统调用——那么你应该使用子进程而不是子线程。杀死一个子进程不会破坏父进程的堆。也就是说，C++ 标准库不提供进程间 API。
【讨论】：
信号是应用程序范围的，不仅适用于线程，因此它可以工作，但对于现实世界的应用程序来说确实很棘手，但这只是一个想法。关于您对不间断系统调用的评论：老实说，不知道您的意思，读取是可中断的，但从其他用户 cmet 看来，这无论如何都不是一个好策略，因此您的评论似乎不适用。 @greywolf82 关于信号是全球性的好点。您需要使用pthread_kill 发送信号，而不是针对正确的线程。太糟糕了，它没有标准的 API。
@JiveDadson & graywolf82 我添加了一个例子。
您的示例代码不起作用，因为 std::signal 将对信号使用 BSD 行为，因此 read 不会返回 EINTR。此外，如果我记得很清楚，它不接受 lambda。
@greywolf82 是的，该示例适用于 POSIX 系统。对于 BSD 信号处理，您可以使用 siginterrupt 设置此方法所依赖的相同行为。我不明白为什么不能使用 lambda。至少在我的系统上运行良好。【参考方案2】：
正如其他人所说，杀死正在运行的线程是个坏主意™。
但是，在这种情况下，您以某种方式知道线程在读取时阻塞，并希望它停止。
一个简单的方法是使用“自我管道技巧”。打开管道，并在select() 或poll() 调用上阻止线程，检查管道的读取端和正在读取的文件描述符。当您希望线程停止时，将单个字节写入写入描述符。线程醒来，看到管道上的字节，然后可以终止。
这种方法避免了直接终止线程的未定义行为，允许您使用阻塞系统调用来避免轮询并且响应终止请求。
【讨论】：
我有点困惑。如果你在 read() 上阻塞并且 read() 被中断，你不必在 poll() 上阻塞，只需快速检查一下 self-pipe 就足够了，不是吗？ @Malkocoglu 问：如果你的阅读被阻塞了，你怎么打断它？ A：没有好办法；关闭描述符具有文件描述符重用竞争条件。使用poll() 的替代方法将告诉您哪个文件描述符已准备好读取，避免了read() 本身阻塞的需要。如果自管道准备好，则线程知道停止。如果文件描述符准备好了，线程可以安全地读取而不会阻塞。
谢谢。你回答中的最后一句话让我很困惑，这是我的错，现在很清楚......
@Malkocoglu 感谢您的反馈——我把最后一句话改写了一下，希望更清楚一点。以上是关于终止线程c ++ 11在读取时阻塞的主要内容，如果未能解决你的问题，请参考以下文章