gpt4 book ai didi

c++ - G_LOCK 行为从 glib 2.46 更改为 glib 2.48?

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

我正在查看一段代码,它直到最近才有效。基本上,我有一个 C++ 类,我在其中使用 G_LOCK_DEFINE 宏保护一个变量。

class CSomeClass {
private:
gulong mSomeCounter;
G_LOCK_DEFINE(mSomeCounter);

public:
CSomeClass ();
}

构造函数在单独的 .cpp 文件中实现。

CSomeClass::CSomeClass()
{
G_LOCK(mSomeCounter);
mSomeCounter = 0;
G_UNLOCK(mSomeCounter);
}

这个变量在几个函数中被访问,但是原理总是一样的。现在,正如已经说过的那样,代码编译得很好,实际上在过去也运行得很完美。现在,从最近开始,每当遇到 G_LOCK 命令时,我都会陷入僵局。为了调试,我已经将程序限制为只有一个线程,以排除逻辑错误。

我最近确实更新到 Ubuntu 16.04 beta,这将我的 glib 版本推到了 2.48.0-1ubuntu4。我已经检查了更改日志以获取有关 G_LOCK 的相关信息,但找不到任何内容。在最近的 glib 版本中使用 G_LOCK 宏时,有没有其他人注意到有趣的效果?我在这里错过了一些变化吗?

最佳答案

首先,G_LOCK_DEFINE 所做的就是创建一个 GMutex 变量,该变量的名称对其保护的变量名称进行编码,例如G_LOCK_DEFINE(mSomeCounter) 变为 GMutex g__mSomeCounter_lock;。所以我们可以将您的代码扩展为:

class CSomeClass {
private:
gulong mSomeCounter;
GMutex g__mSomeCounter_lock;

public:
CSomeClass ();
};

CSomeClass::CSomeClass()
{
g_mutex_lock(&g__mSomeCounter_lock);
mSomeCounter = 0;
g_mutex_unlock(&g__mSomeCounter_lock);
}

这里的根本问题是您没有初始化 CSomeClass 类的任何 成员。您将在构造函数中为它们中的一些 赋值,但绝对不会对它们进行初始化。大括号中的赋值与使用初始化程序之间存在差异,例如:

    CSomeClass::CSomeClass() : mSomeCounter(0)

因此,根据变量命名的互斥锁可能包含垃圾。 glib 代码中可能没有任何更改会导致这种情况发生,更有可能是对其他库的更改改变了您应用程序的内存布局,从而发现了错误。

glib documentation提示您需要 g_mutex_init 互斥量:

that has been allocated on the stack, or as part of a larger structure

您不需要 g_mutex_init 互斥:

It is not necessary to initialize a mutex that has been statically allocated

类实例几乎总是静态分配。

您需要修复您的构造函数以确保它“正确地”初始化互斥锁,例如:

CSomeClass::CSomeClass()
{
g_mutex_init(&G_LOCK_NAME(mSomeCounter));
G_LOCK(mSomeCounter);
mSomeCounter = 0;
G_UNLOCK(mSomeCounter);
}

TBH,我会把互斥体放入一个类持有者中,并将其初始化为其中的一部分,而不是按照您的方式进行初始化,以确保它作为标准 C++ 的一部分进行初始化、锁定和解锁RAII 语义。

如果你使用一个小的主 stub ,像这样:

main() {
{ CSomeClass class1; }
{ CSomeClass class2; }
{ CSomeClass class3; }
}

还有你的代码,它很可能无论如何都会挂起。 (我的 mac 使示例崩溃:GLib (gthread-posix.c):“pthread_mutex_lock”期间 C 库出现意外错误:参数无效。正在中止。

一些简单的示例非生产包装器来帮助 RAII:

class CGMutex {
GMutex mutex;

public:
CGMutex() {
g_mutex_init(&mutex);
}

~CGMutex() {
g_mutex_clear(&mutex);
}

GMutex *operator&() {
return &mutex;
}
};

class CGMutexLocker {
CGMutex &mRef;
public:
CGMutexLocker(CGMutex &mutex) : mRef(mutex) {
g_mutex_lock(&mRef);
}
~CGMutexLocker() {
g_mutex_unlock(&mRef);
}
};

class CSomeClass {
private:
gulong mSomeCounter;
CGMutex mSomeCounterLock;

public:
CSomeClass ();
};

CSomeClass::CSomeClass()
{
CGMutexLocker locker(mSomeCounterLock); // lock the mutex using the locker
mSomeCounter = 0;
}

mSomeCounter 初始化确保计数器被初始化,否则它将有垃圾。

关于c++ - G_LOCK 行为从 glib 2.46 更改为 glib 2.48?,我们在Stack Overflow上找到一个类似的问题: https://stackoverflow.com/questions/36688391/

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