字节对齐导致pthread_cond_timedwait 占用高CPU问题

最新推荐文章于 2024-10-13 19:00:00 发布

pyxllq

最新推荐文章于 2024-10-13 19:00:00 发布

阅读量1.6k

点赞数

CC 4.0 BY-SA版权

分类专栏： linux

本文链接：https://blog.youkuaiyun.com/pyxllq/article/details/109364510

linux 专栏收录该内容

8 篇文章

订阅专栏

博客讲述了在程序中添加内存管理模块导致其他线程CPU占用升高的问题，问题源于pthread_cond_timedwait的超时时间计算错误，以及内存对齐设置的影响。通过调整内存对齐方式，成功降低了CPU占用。

摘要生成于 C知道，由 DeepSeek-R1 满血版支持，前往体验 >

Mark下调试中出现的诡异现象，在程序中添加一个内存管理模块后，导致了其他线程占用高cpu，

该线程的线程栈如下(该线程主要功能就是处理模块间的消息)：

#0 0x00007f81b7d48da2 in pthread_cond_timedwait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0
#1 0x0000000000416a80 in MsgQueue::Dequeue (this=0x13af1961, item=...) at ../public/xx/xxx.h:109
#2 0x0000000000416198 in module_message (arg=0xb0deb0 <ModuleMgr+4848>) at ../public/xx/xxx.cpp:17
#3 0x00007f81b7d44e65 in start_thread () from /lib64/libpthread.so.0
#4 0x00007f81b5e6288d in clone () from /lib64/libc.so.6

查阅资料发现有网友(https://bbs.youkuaiyun.com/topics/390787479)也出现过类似问题，其调用pthread_cond_timedwait代码如下，问题是pthread_cond_timedwait的最后参数outtime赋值错误导致，错误语句：

outtime.tv_nsec = now.tv_usec，两边的单位不一样，一个是纳秒，一个是微秒。这样赋值会使得pthread_cond_timewait的超时时间比当前时间还小。

        gettimeofday(&now, NULL);
        now.tv_usec += ms * 1000;
        if(now.tv_usec >= 1000000)
        {
            now.tv_sec += now.tv_usec / 1000000;
            now.tv_usec %= 1000000;
        }
        outtime.tv_nsec = now.tv_usec;
        outtime.tv_sec = now.tv_sec;
        int ret = pthread_cond_timedwait(&cond, &mutex, &outtime);

而我这里也这么赋值，但是tv_usec*1000后来赋值的，还是出现高cpu，后面各种调试还是高

t.tv_sec = now.tv_sec+1;
t.tv_nsec = now.tv_usec*1000;

小伙伴调试这个部分代码时就是各种coredump，到我这里就是高cpu(说明一下：小伙伴和我使用代码的平台不一样，当然编译器和运行平台不一样)，修改了内存管理模块头文件的对齐方式(原来是1字节对齐，修改为4字节对齐)后，不挂了，我这尝试修改对齐cpu也神奇的降下来了

神奇的字节对齐

后来查阅资料，人家说互斥锁一字节对齐导致的，不知道为什么