Error

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保护下