gpt4 book ai didi

c++ - Boost::Thread 函数导致嵌入式 ARM 出现段错误

转载 作者:搜寻专家 更新时间:2023-10-31 01:54:59 25 4
gpt4 key购买 nike

我在使用 Boost::threads 的线程类中遇到了一个奇怪的问题。以下是我正在做的事情的简要总结:

一个例程创建了一堆对象,这些对象由一个处理程序类和一个私有(private)数据成员组成,该私有(private)数据成员是指向形成继承树的基类的共享指针。我非常有信心这个例程工作正常,而不是问题的一部分。

然后我调用处理程序类 (startUpdate) 的方法,该方法创建我的线程类的新实例。这是线程类代码:

class Sensor_Thread
{
public:
//constructor (creates thread and binds the update function to it
Sensor_Thread (const Ptr<Sensor_Base> & theSensor): m_stoprequested (false),
s (theSensor),
m_thread (boost::bind (&Sensor_Thread::update, this)) { }
//default null constructor, shouldn't ever be used
Sensor_Thread (): m_stoprequested (true),
m_thread (),
s (NULL) { }

//destructor (automatically joins the thread as per RAII principles)
~Sensor_Thread () { m_stoprequested = true; m_thread.join (); }

private:
volatile bool m_stoprequested;
boost::mutex m_mutex;
boost::thread m_thread;
Ptr<Sensor_Base> s;

void update ();

};

(“Ptr”类是我的共享指针类...我非常有信心它可以正常工作,因为我最初是从 C++ 教科书中得到它的...)

更新函数:

void Sensor_Thread::update ()
{
//make sure we actually have a sensor attached...
if (s) {
// set up structure for sleeping
struct timespec time;
while (!m_stoprequested)
{
boost::mutex::scoped_lock lock(m_mutex);
s->update ();
time.tv_sec = s->updateInterval / 1000;
time.tv_nsec = (1000 % s->updateInterval) * (1000 * 1000);
nanosleep (&time, NULL);
}
}
}

这会无限期地运行,直到驱动程序中的另一个触发器调用 stopUpdate 并且 threaded_class 被销毁。

奇怪之处:在我的开发箱 OS X 10.6 上,使用 darwin gcc 4.2.1,它工作正常,完全符合预期。

这是为了在带有 debian linux 和 ARM 处理器的嵌入式服务器上运行。我有一个嵌入式系统制造商提供的交叉编译工具链,当我使用它进行交叉编译时,出现段错误。通过调试,我发现当调用 s->update () 时(或任何其他尝试取消引用共享指针并对其执行某些操作),会发生此段错误。但是,如果我稍微延迟一下,比如添加“sleep(1);”在我的 Sensor_Thread::update 函数中启动 while 循环之前,它运行完美。

在我看来,这似乎意味着系统试图在完全或充分初始化之前取消对共享指针的引用? sleep(1) 解决方法使它工作,但对我来说这仍然很奇怪。如果线程类的共享指针在构造函数期间被初始化,它不应该在更新函数被调用之前准备好吗?或者 boost::thread 的创建是否意味着更新函数与线程类拥有的共享指针的初始化同时发生?有没有比“ sleep ”hack 更干净的方法来确保在调用更新函数之前初始化共享指针?

谢谢!!!

最佳答案

Sensor_Thread (const Ptr<Sensor_Base> & theSensor): m_stoprequested (false),
s (theSensor),
m_thread (boost::bind (&Sensor_Thread::update, this)) { }

此代码已损坏。您正在对尚未构建的对象调用 update。在构造函数的初始化列表中使用 this 应该始终引发危险信号。它是指向尚未完全存在的对象的指针。

处理此问题的通常方法是将其分为两个步骤。具有创建线程的 runstart 方法。在构造函数返回后调用该方法。

while (!m_stoprequested)
{
boost::mutex::scoped_lock lock(m_mutex);
s->update ();
time.tv_sec = s->updateInterval / 1000;
time.tv_nsec = (1000 % s->updateInterval) * (1000 * 1000);
nanosleep (&time, NULL);
}

这可能不是您想要的。它始终持有互斥锁,使得另一个线程很难访问。它将不得不等到下一次更新,然后赢得互斥体的竞争。在一些平台上,一个正在做实际工作的线程将很难击败一个“交互式”线程(一个大部分时间都在 sleep 的线程)。因此,这可能会大大减慢任何其他试图访问 s 的线程。

为什么在持有互斥锁的同时调用nanosleep

关于c++ - Boost::Thread 函数导致嵌入式 ARM 出现段错误,我们在Stack Overflow上找到一个类似的问题: https://stackoverflow.com/questions/8935309/

25 4 0
Copyright 2021 - 2024 cfsdn All Rights Reserved 蜀ICP备2022000587号
广告合作:1813099741@qq.com 6ren.com