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

voipexplore

晕倒
pthread_mutex_lock(&fastmutex);
pthread_mutex_unlock(&fastmutex);
这个不就是加解锁吗，string的性能比它高，不能说明string内部没有使用加解锁吗？

malloc有无加解锁操作先不说，它的性能的确低于加解锁操作，是不是加锁，不敢说，没看malloc子系统源码。

jigloo

恩，两位可能误会了。shan_ghost所说的锁是广义的锁，包括了用CPU的原子指令实现的锁。而voipexplore所说的锁大概专指pthread_mutex_lock

voipexplore

我在同一个平台上，如果std下面的内存池真的有比pthread_mutex还高效的锁机制，那么pthread_mutex还有什么存在的意义。在其它的内存池上也没有发现更高效的锁机制迹象？
非常的纳闷，是想看源码，遍地的宏，走进去差点没出来。

所以我的问题就是std::string 如何实现的线程安全？

jigloo

这种锁的"高效"的原因是因为直接在用户态使用了CPU的指令，比如__gthread_mutex_lock用了x86的xchg。
在没有CPU支持下就只能用pthread_mutex_lock了，比如arm-linux的STL.

shan_ghost

[这个链接据说有病毒？编辑掉……]

锁的根本原理在于原子操作指令；但在不同的应用场合，有许多不同的具体实现。

[ 本帖最后由 shan_ghost 于 2008-7-31 14:50 编辑 ]

voipexplore

楼上的链接里很多病毒。
2.6内核线程库提供的锁还是pthread_mutex,这点有库保证.
当前只能接收"它使用CPU了支持的特殊汇编的指令"这个说法了.

这种特定平台下高效的锁机制,没有被线程库使用,并且平时的使用种很少听到这种用法,其它的内存池也没有使用过,这个现象还是有点不正常呐.

jigloo

不会吧，win32上的InterlockedIncrement, posix的atomic_inc都是这样实现的啊。

[ 本帖最后由 jigloo 于 2008-7-31 14:36 编辑 ]

voipexplore

posix的atomic_inc??
孤陋寡闻了,怎么使用它.怎么man不到呢

有了它,phread_mutex还有什么存在的必要吗?
多谢指点.

jigloo

atomic_inc在atomic.h里面啊。
pthread_mutex_lock可移植性好啊，每个平台都能用。

voipexplore

ok 多谢.
能提供线索,其它的就能baidu google了
可以封装下,能支持atomic_inc就atomic_inc,否则再pthread_mutex_lock.
多谢,有时间测试证明下,我这个平台上的std是否就是atomic_inc的原因.暂时要忙了,来不及测试回帖.
以后会再来回帖的.
多谢!