英特尔 Inspector 报告我的自旋锁实现中存在数据争用
我使用 Windows 中的 Interlocked 函数制作了一个非常简单的自旋锁,并在双核 CPU(两个线程递增变量)上进行了测试;
该程序似乎工作正常(每次都给出相同的结果,但未使用同步时情况并非如此),但Intel Parallel Inspector表示值存在竞争条件+= j (参见下面的代码)。当使用关键部分而不是我的 SpinLock 时,警告消失。
我的 SpinLock 实现是否正确?这真的很奇怪,因为所有使用的操作都是原子的,并且具有适当的内存屏障,并且它不应该导致竞争条件。
class SpinLock
{
int *lockValue;
SpinLock(int *value) : lockValue(value) { }
void Lock() {
while(InterlockedCompareExchange((volatile LONG*)lockValue, 1, 0) != 0) {
WaitABit();
}
}
void Unlock() { InterlockedExchange((volatile LONG*)lockValue, 0); }
};
测试程序:
static const int THREADS = 2;
HANDLE completedEvents[THREADS];
int value = 0;
int lock = 0; // Global.
DWORD WINAPI TestThread(void *param) {
HANDLE completed = (HANDLE)param;
SpinLock testLock(&lock);
for(int i = 0;i < 1000*20; i++) {
for(int j = 0;j < 10*10; j++) {
// Add something to the variable.
testLock.Lock();
value += j;
testLock.Unlock();
}
}
SetEvent(completed);
}
int main() {
for(int i = 0; i < THREADS; i++) {
completedEvents[i] = CreateEvent(NULL, true, false, NULL);
}
for(int i = 0; i < THREADS; i++) {
DWORD id;
CreateThread(NULL, 0, TestThread, completedEvents[i], 0, &id);
}
WaitForMultipleObjects(THREADS, completedEvents, true, INFINITE);
cout<<value;
}
如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

发布评论
评论(3)
二手情话 2024-08-12 21:23:51
对于与我有类似情况的其他穷人:英特尔确实提供了一组包含和库来完成此类事情。检查 Inspector 安装目录(您将在安装目录中看到 \include、\lib32 和 \lib64)以获取这些材料。有关如何使用它们的文档(截至 2018 年 6 月,尽管英特尔并不关心保持链接一致):
https://software.intel.com/en-us/inspector-user-guide-windows-apis-for-custom-synchronization
有 3 个功能:
void __itt_sync_acquired(void *addr)
void __itt_sync_releasing(void *addr)
void __itt_sync_destroy(void *addr)
~没有更多了~
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱,如果其他用户或者作者回复了您的评论,将不能在第一时间通知您!
Parallel Inspector 的数据文档race 建议使用关键部分或互斥体来修复 Windows 上的竞争。其中没有任何内容表明 Parallel Inspector 知道如何识别您可能发明的任何其他锁定机制。
用于分析新颖锁定机制的工具往往是静态工具,它们会查看代码中的每个可能路径,Parallel Inspector 的文档暗示它只执行一次代码。
如果您想尝试新颖的锁定机制,我在学术文献中看到的最常用工具是 Spin模型检查器。还有ESP,这可能会减少状态空间,但我不知道如果它已应用于并发问题,还有 移动性工作台 如果您可以用 pi 演算来表达您的问题,它将进行分析。英特尔 Parallel Inspector 似乎并不像这些工具那么复杂,而是旨在使用启发式方法检查常见问题。
Parallel Inspector's documentation for data race suggests using a critical section or a mutex to fix races on Windows. There's nothing in it which suggests that Parallel Inspector knows how to recognise any other locking mechanism you might invent.
Tools for analysis of novel locking mechanisms tend to be static tools which look at every possible path through the code, Parallel Inspector's documentation implies that it executes the code once.
If you want to experiment with novel locking mechanisms, the most common tool I've seen used in academic literature is the Spin model checker. There's also ESP, which might reduce the state space, but I don't know if it's been applied to concurrent problems, and also the mobility workbench which would give an analysis if you can couch your problem in pi-calculus. Intel Parallel Inspector doesn't seem anything like as complicated as these tools, but rather designed to check for commonly occurring issues using heuristics.