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

voipexplore

原帖由 voipexplore 于 2008-7-31 12:30 发表
对，看起来是线程安全的。从测试结果不coredump就知道。

关键问题就是它如何实现了线程安全，它并没有加锁？？
实现代码里有pthread_mutex_t相关代码，测试感觉并没有加，std::string的对象分配性能远好于加 ...

上面是3楼的

俯卧撑做的还真是快.

权衡只是奇怪如何在保证了线程安全基础上,又保证了性能? 当然当时有关性能的看法都是错误的.现在看来,抠字还是一门学问,幸好当时前面还加了猜测两个字.

嘿嘿 嘿嘿......................................

而兄弟就此扣了一个大帽子,佩服

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

system888net

一般来说,"C++标准库的线程安全性"并没有统一明确的规定，实际上在很大的程度上取决于所用的编译
器. 通常只能说是"部分线程安全的".

lipingtababa

吵个毛,讨论的是函树库有没有加锁,又不是女孩子要嫁给你俩中的哪一个,这么生气干吗

system888net

原帖由 system888net 于 2008-8-1 12:57 发表
一般来说,"C++标准库的线程安全性"并没有统一明确的规定，实际上在很大的程度上取决于所用的编译
器. 通常只能说是"部分线程安全的".

比如SGI的STL里,为了效率,并没有给所有的操作都加锁.
具体看一下:http://www.sgi.com/tech/stl/thread_safety.html

还有VC里的STL 大家也可看看,
等等...

每一个人的观点都有可取之处.从不同的角度看,不会有完全误的观点.

shan_ghost

原帖由 system888net 于 2008-8-1 13:04 发表

比如SGI的STL里,为了效率,并没有给所有的操作都加锁.
具体看一下:http://www.sgi.com/tech/stl/thread_safety.html

还有VC里的STL 大家也可看看,
等等...

每一个人的观点都有可取之处.从不同的角度看,不会有完全误的观点.

不一样的。

比如，考虑下面这种情况会发生什么：

string s1; //string是一个容器

thread1:
s1 += xxx;        //1 stl 一般都无法支持这个
string s2(zzz);  //2 stl 只能完美支持这个

thread2:
s1 += yyy;
string s2(zzz);


——————————————————————————
显然，string的线程安全性是有几个等级的。
1、完全不支持多线程
比如：它使用的内存池本身没有加锁；string内部有静态变量且没有加锁等等。



2、部分支持多线程
比如：使用的内存池有锁；string内部没有静态变量或虽然有静态变量但加了锁等等——SGI的就是这一种，如下：
The SGI STL implementation removes all nonconstant static data from container implementations. The only potentially shared static data resides in the allocator implementations. To this end, the code to implement per-class node allocation in HP STL was transformed into inlined code for per-size node allocation in the SGI STL allocators. Currently the only explicit locking is performed inside allocators.

这种库显然可以完全支持//2 的情形；但//1一定会出事。


3、完全支持多线程
比如，在2的基础上，进一步为每个string对象的每个操作都加了锁——于是，不需要做任何工作，你在任何一个线程读写string都会在内部被保护起来。

于是，这种库就可以完全支持//1了。


所以说，问题非常清晰，没有打马虎眼的余地。

shan_ghost

loki里面就做的非常清晰，它的thread头文件里面就为多线程定义了两个锁： 类级锁和对象级锁。

很显然，类级锁定保护静态变量，提供第二级的部分多线程支持；
而对象级锁保护每个实例，提供第三级的完全多线程支持。


有人见过一个线程声明个vector，另一个线程声明个string，第三个线程声明一个map——所有这些容器都必须放到一起保护起来、否则将捣毁共用内存池的“多”线程库吗？

henying

坐下来看两个傻鸟互掐。

yuyongyu

45楼写得不错，顶下

softarts

原帖由 voipexplore 于 2008-7-31 13:51 发表
呵呵，正好，各位看下下面的代码测试性能有问题吗？
pthread_mutex_t fastmutex = PTHREAD_MUTEX_INITIALIZER;

struct timeval begin;
struct timeval end;
struct timeval interval;
struct timeval ba ...

今天看了看，简单说两句
1.base=36不一定准确，可能被编译器优化掉，gettimeofday也不是很准确，时间可能回退，用clock_gettime或者rdtsc计算cpu cycle更准确
2.多核上pthread_spin_lock比pthread_mutex_lock更快
3.string 的实现很特殊，你那个测试在某些string版本下可能是通过引用来实现的，自然很快
4.new和malloc都是带锁的
5.锁的办法有很多,这个要具体看实现，用原子操作也可以达到'锁'的目的,我最近遇到了string的某个版本有点线程安全的问题，但我现在也没法搞明白,google到这个文章，随便说说

zxcvxxxxxx

晕倒 看主贴，已经说过 用valgrind证实过了的确是调用了malloc。 //究竟是哪里调用的malloc？

//或者我不得不给你科普一下：C++标准里，整个循环体构成一个作用域，循环不结束，作用域不结束。
//初始化语句在这个作用域里只会执行一次——这是常识。
//如果还不明白，拜托阁下给我解释下下边这个循环的执行过程：
for (int i = 0; i >= 100; i++)
{
    int j = 0;
    j += i;
    printf("%d, %d",i,j);
};

shan_ghost 发表于 2008-08-01 09:24

我也是从Google 穿越过来的，别的不说，就说shan_ghost 贴的这段程序就能看出shan_ghost 够自以为是的，无语

这段程序里面的for body根本没法运行，int i = 0; i >= 100，真够神马的

改成int i = 0; i <= 100，结果无论是GCC还是G++编译，结果都证明j每次都被初始化成了0


./a.out
0, 0
1, 1
2, 2
3, 3
4, 4
5, 5
6, 6
7, 7
8, 8
9, 9
10, 10
11, 11
12, 12
13, 13
14, 14
15, 15
16, 16
17, 17
18, 18
19, 19
20, 20
21, 21
22, 22
23, 23
24, 24
25, 25
26, 26
27, 27
28, 28
29, 29
30, 30
31, 31
32, 32
33, 33
34, 34
35, 35
36, 36
37, 37
38, 38
39, 39
40, 40
41, 41
42, 42
43, 43
44, 44
45, 45
46, 46
47, 47
48, 48
49, 49
50, 50
51, 51
52, 52
53, 53
54, 54
55, 55
56, 56
57, 57
58, 58
59, 59
60, 60
61, 61
62, 62
63, 63
64, 64
65, 65
66, 66
67, 67
68, 68
69, 69
70, 70
71, 71
72, 72
73, 73
74, 74
75, 75
76, 76
77, 77
78, 78
79, 79
80, 80
81, 81
82, 82
83, 83
84, 84
85, 85
86, 86
87, 87
88, 88
89, 89
90, 90
91, 91
92, 92
93, 93
94, 94
95, 95
96, 96
97, 97
98, 98
99, 99
100, 100