std::string多线程下为什么不coredump？

voipexplore

@shan_ghost
我的本意是来问问题,不是解决问题.
第一,哥们有想当然.(1)阁下认为锁开销不能测试(2)阁下认为func开销很大.
第二,"这里是会分配几次内存：_alloc本身就需要分配内存；然后要为123分配空间(通过_alloc)
",再详细解释下吧,不够明白.
第三,哥们不要继续想当然了,阁下跑下自己的程序好吗:
for (int i = 0; i >= 100; i++)
{
    int j = 0;
    j += i;
    printf("%d, %d",i,j);
};
先告诉你,小细节自己调整吧,我就不给你调整了.
最后,还是主贴,本意是来问问题,不是讲问题,任何错误欢迎指正,"在下从一开始不相信阁下有设计出检验string内部内存分配性能的用例的资质、到后面被你的大话蒙蔽、再到重新认识您没有这个能力，走了一个无聊的大圈。",哥们给个有建设性的测试以及结果啊.

哥们给了大量的无关解决问题,没有正确指导意义,于解决问题无关的指导,从开始跟帖就讽言讽语. 很遗憾,不能平静的探讨问题,本人水平有限,尤其在不熟悉的stl内存池部分.

[ 本帖最后由 voipexplore 于 2008-8-1 09:51 编辑 ]

voipexplore

不过当前结果已经很明确了.
按照shan_ghost 讽言讽语的指点,测试结果,的确string开销远大于加解锁测试,性能很低下.
有这个结论就够了.
多谢@shan_ghost,给的很有用处的一个提示就是 不进行写操作,不引起实际的内存分配动作. 其它的全是屁话.
还是要多谢

[ 本帖最后由 voipexplore 于 2008-8-1 10:06 编辑 ]

shan_ghost

26楼的资料很好，且绝对和主题有关

string的copy on write实现本身就依赖引用计数。
这种string内部实现可用伪码表示如下(为简单计，忽略一切泛型相关问题)：

struct inner_storage
{
   uint ref_count(0);
   char * pMem;
}

class string
{
   private:
      inner_storage * p;
   public:
      //当前对象作为左值使用时
    {
          保存inner_storage * p
          if //赋值/初始化
       {
             //复制源string的inner_storage * p 且 p->ref_count++;
                   //多线程环境，++操作需要保护(锁，不可直接atomic_inc)
           }
           else
           {
                   //为inner_storage * p分配空间
             //这里可以优化
             //   如: 若ref_count为1则说明目前此块为本string实例独享
             //         于是前面的内存分配操作可优化掉
             //         此时后面的ref_count--也要做调整
             //视情况检查是否需要复制旧的字符串，然后完成修改动作
            }
            //旧inner_storage * p指向结构的ref_count--;re_fcount为0则删除
        //这里的--操作同样需要锁保护
      }
}

昨天还是有点仓促，没有仔细考虑多线程环境下string的copy on write究竟该如何实现。


现在看来，如果string使用了上述优化，那么锁还是逃不过。
测试结果错误，显然只与楼主的测试方法或判断有关。


另外，stl容器一般会用稍微多分配一些内存空间的办法避免多次重新分配；内容清空，内存空间一般不会归还。
stl内存池一般只为加速小块内存的使用而设计；大于一定大小的内存会直接交给系统管理；内存归还时，也不一定第一时间把它们挂回free链表——某些基于trunk的实现会把它们加入可回收队列中；只有池中空间不足时才真正执行回收操作。

这些都是设计测试用例时必须仔细考察的。



最后：
根本不存在牺牲线程安全换取性能这种说法。要么完全支持，要么老老实实说不支持。
从根本上，这种说法等同于“用偶尔的crash、死机、破坏用户数据来换取执行速度”——显然，这不是人话。

shan_ghost

呵呵，我告诉过你，一条半个时钟周期的整数指令都能测出执行时间——锁居然不能测试？

不好意思，在下是不相信你能写出可以测试出string有无锁情况下执行性能的用例——阁下的阅读理解能力何其差也。


函数调用开销之大有目共睹，只是当前的cpu都专门为它们做了很多优化而已。
比如，AMD某款CPU就假定： 任何条件跳转指令最终都要跳转。
for循环调用func显然刚好符合这个预测，自然看起来没有额外开销。
但稍微复杂的场合，在下没胆量乱说——给出数据之前只能存疑。


另外，i++、3条简单指令都到了11、36，func调用只有36：您不觉得您的这个特例太特了一点吗？

正常情况下，一个func调用至少要经过： 寄存器保护、参数压栈、call、保存返回值、ret、恢复寄存器六步——这还只是一个类似int func(int i) {return i};的空函数！

它的执行消耗居然低于3条简单指令？
在下对得出这个结论的人实在佩服的紧。

shan_ghost

测试结果,的确string开销远大于加解锁测试,性能很低下.

这怎么又和你前面的数据矛盾了？


问问题也要有个问问题的态度。

具体场景只有你自己知道——至今我对你使用什么CPU、操作系统以及内存条类型等等细节都毫无所知；甚至连那个pthread锁是库还是给了源代码、编译器的优化选项统统都不知道。

我所能做的，只能是根据自己的经验，从任何可能的角度提出问题，以确认阁下究竟遇上了什么情况。
在把情况搞清之前，在下当然只能从任何相关的方面开始试探，直到确切明白究竟是什么情况。



很显然，从阁下一开始就咋咋呼呼声称gcc的内存池多线程下没有用锁开始，在下就觉得你不太可能有能力设计出有效测试用例（尤其是测的还是以实现复杂著称的string）——于是，告诉你锁其实极快，不是随随便便就能测出来的。

不过，在下还是太容易相信人了。居然一度相信你的用例正确，还去查了不少各种系统下高性能锁的实现方式——最终发现都很难解释你的测试结果；这才回过头来，重新考察你的用例。


最后：
在下对头脑简单、张嘴就下结论的家伙素无好感——尤其是当他们犯错的速度远远超过在下的打字速度时。
对这类人，要么干脆不理，要么就用夸张、滑稽的反例凸显其错误。
如果这让您有了在下喜欢“讽言讽语”的印象的话，说明在下说话还是太温和、讽刺还是太无力了。

——想来也是，遇上类似振振有辞21ms攻击70ns慢的情况（相差30万倍！），在下居然不能让读者捧腹，显然讽刺的水平和力度也太低了点 ；看来在下的语言能力还是需要继续锻炼锻炼了

——当然，还有一个极小的可能，就是您还没有足够的能力和直觉，去意识到在下是在指出低级错误（嗯，您水平这么高，经验如此丰富，显然不会是这样的）。

voipexplore

哈哈
佩服网络斗士shan_ghost
屎一般的一大陀 对问题已毫无意义的一陀

voipexplore

(1)33楼的string描述已经没有问题了,对内存池的描述只能满足你炫耀的自满心态.

(2)根本不存在牺牲线程安全换取性能的说法不存在,你自己认为吧.现实的系统开发种,多少个对象是单线程中执行的,单线程的对象池的实用意义远大于线程安全的对象池.

(3)"不好意思，在下是不相信你能写出可以测试出string有无锁情况下执行性能的用例——阁下的阅读理解能力何其差也",这句我只能当屁话飘过.

(4)"函数调用开销之大有目共睹",这个问题还争论,只能说明懒惰,看看汇编就知道了.  
(5)"稍微复杂的场合，在下没胆量乱说——给出数据之前只能存疑", 很超然啊,给点有建设性的说法好不好.
(6)"从阁下一开始就咋咋呼呼声称gcc的内存池多线程下没有用锁开始",屁话,没疑问没错误的认识来发帖做什么.

(7)"这怎么又和你前面的数据矛盾了？",这是发帖子的本意,原因很明显,测试用例没有反映现实.当然你可以就测试用例再继续反驳我.

(阁下居然一度相信我的用例正确,的确 我发帖以前也认为测试用例的正确,否则也不会有这个帖子
(9)"于是，告诉你锁其实极快，不是随随便便就能测出来的.",来点建设性的,这句话本身毫无意义.
(10)"在下对头脑简单、张嘴就下结论的家伙素无好感",指我吗, 初学,头脑自然简单点,就我本身能看到的现象得出结论很正常,而结论很奇怪,故有此帖.
(11)"如果这让您有了在下喜欢“讽言讽语”的印象的话，说明在下说话还是太温和、讽刺还是太无力了。",飘过.
(12)"嗯，您水平这么高，经验如此丰富",对解决问题毫无帮助,而又影射人身的语言,只能继续当屁话飘过.

shan_ghost

1、CU果然很危险～～回帖说点楼主不知道的就要被打成“炫耀”！

加个规则好不好：
  今后大家看到楼主，凡觉得自己必须45度仰望的进来拜之；凡觉得自己可能会因为“炫耀”惹恼楼主的，自觉到一边做俯卧撑去。


2、既然已经“炫耀”过了，在下干脆再“炫耀”下：
在下原话是“根本不存在牺牲线程安全换取性能这种说法。要么完全支持，要么老老实实说不支持。”，结合前后语境，相信小学毕业程度都该知道这句话的本意是什么。

——在下其实很想表扬表扬楼主29楼的东西：多线程环境下，说人家gcc库“牺牲线程安全换取性能”：真是太好太强大了。



最后，告诫各位网友： 在下的前车之鉴你们一定要谨记在心——但凡见了楼主，不以45度角仰视或一边自觉做俯卧撑的，一旦刺痛了楼主脆弱的小心灵，就会变成在下一样的“网络斗士”，说的话也都会变成“屁话”。

这是血的教训，诸位切莫忘记。

在下就此别过，到一边补10000000个俯卧撑去也～～

voipexplore

哈哈
慢走 不送

*"在下其实很想表扬表扬楼主29楼的东西：多线程环境下，说人家gcc库“牺牲线程安全换取性能”：真是太好太强大了。",你就意淫吧. “牺牲线程安全换取性能”,这么白痴的说法你也能想到,佩服.

去打酱油了.

shan_ghost

原帖由 voipexplore 于 2008-8-1 09:14 发表
关键的对比不是string和malloc,是string和加解锁........................................
valgrind的测试,只是证实下面内存池的存在,所以猜测低层内存池在线程安全和性能之间的权衡...............

hia~~hia~~~~hia~~~~~~~~~~