VCZH.粉絲數組[0]<errorcpp@qq.com>  18:45:53
尼瑪，我現在要讀寫鎖
哪為接我一個
等boost能用了還給你
vczh四號粉絲(342775210)  18:46:25
不優化性能
優化啥啊,根本就沒性能問題
(逃

這摩托上班看著不錯
VCZH.粉絲數組[0]<errorcpp@qq.com>  18:47:08
我去
難道你們都不用讀寫所的，，，
hzcv.粉絲數組[-1](450635425)  18:47:04
想要一個
我以前有一個，但明顯沒這個號
vczh四號粉絲(342775210)  18:47:18
必須不用
讀寫鎖就是搓
hzcv.粉絲數組[-1](450635425)  18:47:31
普通鎖不行嗎？
vczh四號粉絲(342775210)  18:47:36
是啊
普通的鎖這么好
VCZH.粉絲數組[0]<errorcpp@qq.com>  18:47:50
尼瑪，讓我做框架
那群隊友都懶的不行啊
我讓他用鎖 他不樂意
一定要我在底層全部搞完了
vczh四號粉絲(342775210)  18:48:22
直接用手槍轟死他們
VCZH.粉絲數組[0]<errorcpp@qq.com>  18:49:39
就是個加載自動更新的東西
原來是一個bool類型沒有用鎖保護
現在我來做，我想還是保護下
vczh四號粉絲(342775210)  18:49:46
用atomic
VCZH.粉絲數組[0]<errorcpp@qq.com>  18:49:53
尼瑪問題就來了
問題是
他們要要求加載的時候 讀動作能自動掛起
又要偷懶
VCZH.粉絲數組[0]<errorcpp@qq.com>  18:52:07
我繼續去糞堆里拔東西
哎
vczh四號粉絲(342775210)  18:52:10
atomic不行嘛?
hzcv.粉絲數組[-1](450635425)  18:52:42
讀寫留兩個函數
VCZH.粉絲數組[0]<errorcpp@qq.com>  18:52:58
這樣的

有個mutex 加載的時候lock上，bool ture
hzcv.粉絲數組[-1](450635425)  18:52:52
用mutex一夾，OK
VCZH.粉絲數組[0]<errorcpp@qq.com>  18:53:02
然后查詢的時候
不理會mutex
監視到ture才 unlock
vczh四號粉絲(342775210)  18:54:41
你那個是windows
不能用mutex夾
windows得用spin lock 夾
(逃
vczh.lsbandar(14735407)  18:55:04
。。。 
關鍵段不用 
用什么spinlock 
hzcv.粉絲數組[-1](450635425)  18:55:41
CriticalSection
hzcv.粉絲數組[-1](450635425)  19:00:28
Spinlock是什么？
hzcv.粉絲數組[-1](450635425)  19:02:19
#if defined(UNIX)
pthread_mutex_lock(&mutex_agent_list);
#elif defined(WINDOWS)
EnterCriticalSection(&cs_agent_list);
#endif

SpinLock和CriticalSection有什么不同啊？
vczh.Iskandar<vczh@163.com>  19:03:04
criticalsection是遞歸的
 
同一個線程可以enter兩次
 
都沒問題
 
leave兩次
 
VCZH.粉絲數組[5](110086478)  19:03:28
sscanf 的性能比較差？
vczh.lsbandar(14735407)  19:03:40
還可以 
hzcv.粉絲數組[-1](450635425)  19:03:53
哦？遞歸的？
IC
VCZH.粉絲數組[0]<errorcpp@qq.com>  19:08:43
個人感覺
可遞歸鎖
就是一個大坑
vczh.Iskandar<vczh@163.com>  19:11:32
有什么好坑
 
你要是當她不能遞歸
 
那就跟別的一樣了
 
坑只會更少
 
ooseven(147340642)  19:12:57
同一個線程下什么場景會導致連續申請鎖兩次？
VCZH.粉絲數組[5](110086478)  19:13:08
parse一個IP地址，有沒有比sscanf更快的
ooseven(147340642)  19:13:19
同一線程下的程序不都是按順序來的嗎？
vczh.Iskandar<vczh@163.com>  19:13:29
可以遞歸的鎖
 
具有可組合性
 
寫起代碼省心多了
 
VCZH.粉絲數組[0]<errorcpp@qq.com>  19:14:13
很多吭
ooseven(147340642)  19:14:16
我的意思是說，同一線程下的代碼，怎么會有并發申請鎖的機會？
vczh.Iskandar<vczh@163.com>  19:14:23
不會
 
但是你可以申請他兩次
 
VCZH.粉絲數組[0]<errorcpp@qq.com>  19:14:50
偷懶
Yaoxin(7936511)  19:14:43
 比如插入一個值，這個插入代碼中又要算長度。 
ooseven(147340642)  19:14:44
有啥好處呢？
vczh.Iskandar<vczh@163.com>  19:14:46
人懶不能怪工具
 
ooseven(147340642)  19:15:15
申請鎖兩次有啥好處？
vczh.Iskandar<vczh@163.com>  19:15:22
這個嘛
 
譬如說我一個類的所有函數
 
都申請了那個鎖
 
結果有一天
 
這種設計還是很常見的吧
 
我一個函數要調用另一個函數了
 
省點代碼
 
你用criticalsection
 
vczh.lsbandar(14735407)  19:15:49
可以遞歸 
ooseven(147340642)  19:15:50
了解
vczh.Iskandar<vczh@163.com>  19:15:52
就不會自己鎖死自己了
 
ooseven(147340642)  19:15:57
這樣也行
！
vczh.lsbandar(14735407)  19:16:06
避免你寫出傻逼的死鎖程序 
這幾乎是必須的 
ooseven(147340642)  19:16:23
啥啊，這是大bug吧
vczh.Iskandar<vczh@163.com>  19:16:26
不是
 
vczh.lsbandar(14735407)  19:16:32
特別是你只用scope的時候 
vczh.Iskandar<vczh@163.com>  19:16:32
criticalsection
 
就是為了讓你這么用的
 
還有，windows有些東西是有own的概念的
 
ooseven(147340642)  19:16:54
如果這不算bug，允許這樣的設計的話，那么鎖兩次也不夠啊
vczh.Iskandar<vczh@163.com>  19:16:54
譬如mutex
 
你一個線程得到了一個mutex
 
這個mutex就掛在你的線程下面了
 
這個時候你可以不斷地得到她
 
也是遞歸的
 
但是event沒有owner
 
所以對于一個autoresetevent
 
vczh.lsbandar(14735407)  19:17:26
遞歸鎖是重要特性 
vczh.Iskandar<vczh@163.com>  19:17:27
你連續wait兩次
 
就會傻逼
 
不然你覺得為什么windows會搞出這么多鎖
 
其實他們是不一樣的
 
ooseven(147340642)  19:18:08
一般同一個類里的函數我都會設計一個參數 void process(..., bool isLock = true);
vczh.Iskandar<vczh@163.com>  19:18:14
何苦呢
 
你就用criticalsection
 
無論如何enter一把
 
多省事
 
VCZH.粉絲數組[0]<errorcpp@qq.com>  19:18:53
ooseven(147340642)  19:18:08
一般同一個類里的函數我都會設計一個參數 void process(..., bool isLock = true);

這個思路不錯偷懶了
ooseven(147340642)  19:18:42
那兩次也不夠用啊
VCZH.粉絲數組[0]<errorcpp@qq.com>  19:19:01
但是出錯搞起來也更加苦逼了
vczh.Iskandar<vczh@163.com>  19:18:47
不是兩次
 
vczh.lsbandar(14735407)  19:18:50
傻逼 
vczh.Iskandar<vczh@163.com>  19:18:53
是不受限制的
 
你enter100次
 
也沒問題
 
vczh.lsbandar(14735407)  19:18:58
你想什么呢都 
ooseven(147340642)  19:19:02
哦，了解了
vczh.Iskandar<vczh@163.com>  19:19:03
誰他媽會有個2
 
只要你也leav 100ci就好了
 
多2
 
ooseven(147340642)  19:19:13
今天又有收獲，哈
vczh.Iskandar<vczh@163.com>  19:19:15
就算你要給個上限
 
那也得是9！
 
ooseven(147340642)  19:19:57
windows下所有的鎖都是同一線程下不鎖嗎？
vczh.lsbandar(14735407)  19:19:58
一定要有遞歸鎖 
用起來才舒服 
vczh.Iskandar<vczh@163.com>  19:20:34
不是
 
event就不是“鎖”
 
遞歸一下就所思自己了
 
semaphore也不是遞歸的
 
所以semaphore(max=1)并不等于mutex
 
而criticalsection和mutex的區別是
 
vczh.Iskandar<vczh@163.com>  19:21:39
cs帶spin而且不能跨進程
 
vczh.lsbandar(14735407)  19:21:52
凡是信號模型的 
都是不能重入的 
vczh.Iskandar<vczh@163.com>  19:22:12
而semaphore(max=1)勉強跟auto reset event一樣
 
vczh.lsbandar(14735407)  19:22:19
比如vc的例子 
vczh.Iskandar<vczh@163.com>  19:22:21
但是auto reset只是普通event的一個屬性
 
所以這些東西都是不能互相替代的
 
vczh.lsbandar(14735407)  19:22:38
但是所有的資源鎖都能重入 
ooseven(147340642)  19:22:51
我基本只用Cristalsection
vczh.lsbandar(14735407)  19:22:52
還有就是 
cs只能匿名 
vczh.Iskandar<vczh@163.com>  19:23:02
用cs你就不需要islock參數了，直接干掉他
 
隨便你鎖
 
從未來‏?過‪(815330718)  19:23:12
加鎖兩次,就要解鎖兩次
vczh.Iskandar<vczh@163.com>  19:23:41
解鎖兩次就兩次
 
不就是把一個變量從1設置為0嗎
 
會有多慢
 
（逃
 
ooseven(147340642)  19:24:36
我只管加鎖，不管解鎖，解鎖都交給析構函數了
從未來‏?過‪(815330718)  19:24:41
我是說鎖 重入.
vczh.Iskandar<vczh@163.com>  19:24:52
臥槽
 
加鎖跟解鎖
 
當然是構造函數一個
 
析構函數一個了
 
你居然
 
ooseven(147340642)  19:25:12
我是說不手動解鎖
從未來‏?過‪(815330718)  19:25:44
那你手動加鎖...加了兩次,只能解鎖一次了..
ooseven(147340642)  19:26:00
不會啊，構造兩次，當然就析構兩次
AutoLock Lock(Cristalsection);
以后就不管了
vczh.Iskandar<vczh@163.com>  19:26:46
所以你那個islock參數
 
就這么干掉吧
 
ooseven(147340642)  19:27:04
嗯，以前還不知道有這特性
VCZH.粉絲數組[0]<errorcpp@qq.com>  19:29:46
condition 和 mutex
分別適應的場合

今天他又學了不少東西
膜拜
vczh.Iskandar<vczh@163.com>  19:29:53
condition variable是一個牛逼的東西
 
一定要掌握
 
VCZH.粉絲數組[0]<errorcpp@qq.com>  19:30:34
我們這邊隊友 wait_condition之前
vczh.Iskandar<vczh@163.com>  19:30:15
回家
 
VCZH.粉絲數組[0]<errorcpp@qq.com>  19:30:41
不鎖mutex
從未來‏?過‪(815330718)  19:30:21
condition variable 不會
 

VCZH.粉絲數組[0]<errorcpp@qq.com>  19:30:48
求解釋
vczh.Iskandar<vczh@163.com>  19:30:28
不是啊
 
VCZH.粉絲數組[0]<errorcpp@qq.com>  19:30:54
這是不要吐槽
vczh.Iskandar<vczh@163.com>  19:30:37
condition是和cs
 
一起用的啊
 
VCZH.粉絲數組[0]<errorcpp@qq.com>  19:31:15
不是和mutex一起的么
api參數都是這樣
vczh.lsbandar(14735407)  19:31:10
和event一起 
vczh.Iskandar<vczh@163.com>  19:31:11
api名字我忘了但是大概就是
 
VCZH.粉絲數組[0]<errorcpp@qq.com>  19:31:33
condition_wait的時候要給一個mutex進去
vczh.Iskandar<vczh@163.com>  19:31:25
WaitForConditionVariableCS/SRW(condition, cs/srw)
 
沒有mutex
 
回家
 
VCZH.粉絲數組[0]<errorcpp@qq.com>  19:32:14
囧


condition是和cs一起用很爽，應為CS可以不需要在mutex保護下