我正在对多线程服务器的关闭进行编码.如果一切顺利,所有线程都应该自行退出,但是线程卡住的可能性很小.在这种情况下,使用非阻塞连接会很方便所以我能做到.
有没有办法做一个非阻塞的pthread_join？某种定时加入也会很好.
这样的事情:
foreach thread do
nb_pthread_join();
if still running
pthread_cancel();
我可以考虑更多的情况,其中一个非bloking连接将是有用的.
因为似乎没有这样的功能所以我已经编写了一个解决方法,但它并不像我想的那么简单.
有没有人知道从pthread_t到GDB用信息线程显示的方法？
所以我有:
(gdb) info threads
37 Thread 22887 0xb7704422 in __kernel_vsyscall ()
36 Thread 22926 0xb7704422 in __kernel_vsyscall ()
35 Thread 22925 0xb7704422 in __kernel_vsyscall ()
34 Thread 22924 0xb7704422 in __kernel_vsyscall ()
33 Thread 22922 0xb7704422 in __kernel_vsyscall ()
32 Thread 22921 0xb7704422 in __kernel_vsyscall ()
(gdb) p m_messageQueue->m_creationThread
$3 = 2694822768
(gdb) p/x m_messageQueue->m_creationThread
$4 = 0xa09fbb70
有谁知道我怎么弄清楚这是哪个线程？它似乎是22768,但我的线程都没有那么低.
我正在使用pthreads创建一个包含多个线程的程序.
是sleep()导致进程(所有线程)停止执行还是只是我调用的线程sleep？
我真的不确定POSIX对fork存在线程和信号的安全性的要求.fork被列为异步信号安全功能之一,但如果库代码有可能注册了pthread_atfork非异步信号安全的处理程序,这是否会否定安全性fork？答案取决于运行信号处理程序的线程是否可以使用atfork处理程序所需的资源？或者换句话说,如果atfork处理程序使用同步资源(互斥体等)但是fork从一个从不访问这些资源的线程中执行的信号处理程序调用,程序是否符合要求？
在这个问题的基础上,如果"线程安全"分叉在系统库内部使用建议的惯用语实现pthread_atfork(获取prefork处理程序中的所有锁并释放父和子postfork处理程序中的所有锁),那么就是fork安全的在线程程序中使用信号处理程序？处理信号的线程是否可能处于调用malloc或fopen/ fclose和持有全局锁的过程中,从而导致死锁fork？
最后,即使fork在信号处理程序中是安全的,在信号处理程序中是否安全fork然后从信号处理程序返回,或者fork在信号处理程序中进行调用总是需要后续调用函数_exit或其中一个exec函数.信号处理程序返回
我想通过控制哪些线程执行时调试多线程程序.我正在使用C++和gdb.除主线程之外我有两个线程(对于示例程序),我想调试一个线程,同时保持另一个线程停止.
这是我写的示例程序:
#include <iostream>
#include <pthread.h>
#include <stdlib.h>
#define NUM_THREADS 2
using namespace std;
void * run (void *) {
for (int i = 0; i < 3; ++i) {
sleep(1);
cout << i << " " << pthread_self() << endl;
}
pthread_exit(NULL);
}
int main (int argc, char** argv) {
cout << "Start..." << endl;
int rc;
pthread_t threads[NUM_THREADS];
for (int i = 0; i < NUM_THREADS; ++i) {
rc = pthread_create(&threads[i], NULL, run, NULL);
if (rc) {
cout …我可以生成一个线程pthread_create并std::mutex安全地使用它吗？
我认为如果std::mutex实现为a pthread_mutex_t那么它会很好,但我没有看到任何记录
例如:
#include <pthread.h>
#include <mutex>
namespace {
std::mutex global_lock;
}
void* thread_func(void* vp) {
// std::mutex used in thread spawned with pthread_create
std::lock_guard<std::mutex> guard(global_lock);
// critical section
return nullptr;
}
int main() {
pthread_t tid;
pthread_create(&tid, nullptr, thread_func, nullptr);
pthread_join(tid, NULL);
}
顺便说一下,我正在运行Debian Wheezy.
cmake 部分输出如下所示：
-- Performing Test CMAKE_HAVE_LIBC_PTHREAD
-- Performing Test CMAKE_HAVE_LIBC_PTHREAD - Failed
我们有一个C++共享库,它使用ZeroC的Ice库来实现RPC,除非我们关闭Ice的运行时,否则我们观察到子进程挂在随机互斥锁上.Ice运行时启动线程,具有许多内部互斥锁并保持打开文件描述符到服务器.
另外,我们有一些我们自己的互斥体来保护我们的内部状态.
我们的共享库被数百个内部应用程序使用,因此我们无法控制进程何时调用fork(),因此我们需要一种方法来安全地关闭Ice并在进程分叉时锁定我们的互斥锁.
在pthread_atfork()上阅读关于处理互斥锁和内部状态的POSIX标准:
或者,某些库可能只能提供一个子例程,它将库中的互斥锁和所有关联状态重新初始化为某个已知值(例如,最初执行映像时的状态).但是,这种方法是不可能的,因为如果互斥锁或锁仍然被锁定,则允许实现失败*_init()和*_destroy()调用互斥锁和锁.在这种情况下,子例程无法重新初始化互斥锁和锁.
在Linux上,此测试C程序从子pthread_atfork()处理程序中的pthread_mutex_unlock()返回EPERM.Linux需要将_NP添加到PTHREAD_MUTEX_ERRORCHECK宏以便进行编译.
这个程序是从这个好的线程链接的.
鉴于在解锁或破坏子进程中的互斥锁在技术上是不安全或合法的,我认为最好有指向互斥锁的指针,然后让子进程在堆上创建新的pthread_mutex_t并让父进程的互斥锁独立,从而拥有小内存泄漏.
唯一的问题是如何重新初始化库的状态,我正在考虑重新设置pthread_once_t.也许是因为POSIX有一个pthread_once_t的初始化程序,它可以重置为初始状态.
#include <pthread.h>
#include <stdlib.h>
#include <string.h>
static pthread_once_t once_control = PTHREAD_ONCE_INIT;
static pthread_mutex_t *mutex_ptr = 0;
static void
setup_new_mutex()
{
mutex_ptr = malloc(sizeof(*mutex_ptr));
pthread_mutex_init(mutex_ptr, 0);
}
static void
prepare()
{
pthread_mutex_lock(mutex_ptr);
}
static void
parent()
{
pthread_mutex_unlock(mutex_ptr);
}
static void
child()
{
// Reset the once control.
pthread_once_t once = PTHREAD_ONCE_INIT;
memcpy(&once_control, &once, sizeof(once_control));
}
static void
init()
{
setup_new_mutex();
pthread_atfork(&prepare, &parent, &child); …我正在将一个中等大小的C++代码移植到Android NDK.不幸的是,pthreads实现(无论如何,NDK v5)都是不完整的.具体来说,我们的应用程序依赖于pthread_cancel()来终止工作线程.NDK没有实现pthread_cancel()!当工作线程正常响应时,还有其他明显的答案.但是在工作线程没有响应的情况下(例如无限循环),如何在不杀死整个过程的情况下取消它？
直到最近,我的印象是,如果你在产生线程后"分离"一个线程,那么即使在"主"线程终止之后线程仍然存在.
但是一个小实验(如下所列)与我的观点相反.我希望分离的线程继续打印"从分离的线程说话",即使在主要终止之后,但这似乎并没有发生.该应用程序显然终止了......
"主要"问题返回0后,"分离"线程是否死亡？
#include <pthread.h>
#include <stdio.h>
void *func(void *data)
{
while (1)
{
printf("Speaking from the detached thread...\n");
sleep(5);
}
pthread_exit(NULL);
}
int main()
{
pthread_t handle;
if (!pthread_create(&handle, NULL, func, NULL))
{
printf("Thread create successfully !!!\n");
if ( ! pthread_detach(handle) )
printf("Thread detached successfully !!!\n");
}
sleep(5);
printf("Main thread dying...\n");
return 0;
}