|
[原创]原创读写锁,求测试
不是说没法找到方法避免,而是整个设计根本不会允许你有可能重构,比如积淀了10年的代码,随便哪个人都不会允许你随便重构……即使问题再多也一样 而且,只要不要重入逻辑,我这个代码立马可以少至少一半 |
|
[原创]原创读写锁,求测试
重入问题,这个是不可避免的。除非所有的东西都是你自己一个人搞。工程变大而且多个对象用一个锁,多个人完成项目时,不允许重入的话,会是噩梦的。而且多数时候,也不会允许你重构 |
|
[原创]原创读写锁,求测试
与线程半路挂掉没关系,这个与那些带超时机制的普通锁的原因一样,没什么好说的 |
|
[原创]原创读写锁,求测试
第一,代码长短的问题,这个实际上没有个绝对的标准,你说长了就长了吧;关于隐藏bug的,麻烦不吝赐教随便点出几个。 第二,这个之前就说过了,只需要把CRITICAL_SECTION改成支持超时的锁对象,比如event等等,就能有超时机制。 第三,锁机制本身就是与进线程以及操作系统、硬件密切相关的,那些所谓夸平台的锁,无非是写了两份代码,保持了对外接口不变而已。 第四,nt6系统那个锁重入有问题,n久前就试过了 第五,booost那个,不支持锁重入,就是因为这个问题,导致产品出了问题,所以才要自己写。另外有个支持重入的锁,那个没法用在读写锁环境里 |
|
杀毒公司员工还原真实的熊猫烧香毒王李俊
你觉得那东西牛在哪里?除了他更会炫耀,所以引得更多人注意外,真的讲技术的东西,我没觉得它比其他那些老掉牙的感染性病毒高级多少 |
|
[求助]拦截驱动加载
不用hook做不了事情么……更何况加载驱动人家未必走loaddriver |
|
|
|
[原创]原创读写锁,求测试
超时的逻辑处理起来到不是太复杂 我只要把CRITICAL_SECTION的那几个变量全换成内核事件对象,比如mutex,EVENT等等,就能支持超时处理。你可以看到我那个try函数里是有失败后的处理的,如果换成支持try和超时的内核对象,比如mutex,就很容易做出支持超时的接口了,与try那个区别不大(try那几个接口可以看做是超时为0的支持超时的接口) 不过效率考虑(临界区的效率肯定会比内核对象的效率高很多),加上目前多数时候没这个需求,我不想这么做 |
|
[原创]原创读写锁,求测试
那也就是限定了我的测试样例中说的那个全局变量,也就是锁变量,在一个进程范围内最多只可以有32个 这个我想多数时候都够了 而且即使真的出现这个情况,也是有其它方法可以解决的,这个不是什么严重问题 |
|
[原创]原创读写锁,求测试
所以嘛,我这个支持了除了你说的支持的外,你不支持的那些情况我这里也有支持,之所以有那些在你口中的“复杂”,也就是因为要支持这些你不支持的,否则这些逻辑很多都不需要。 还有,你的写优先哪里体现出来的 |
操作理由
RANk
{{ user_info.golds == '' ? 0 : user_info.golds }}
雪币
{{ experience }}
课程经验
{{ score }}
学习收益
{{study_duration_fmt}}
学习时长
基本信息
荣誉称号:
{{ honorary_title }}
能力排名:
No.{{ rank_num }}
等 级:
LV{{ rank_lv-100 }}
活跃值:
在线值:
浏览人数:{{ visits }}
最近活跃:{{ last_active_time }}
注册时间:{{ user_info.create_date_jsonfmt }}
勋章
兑换勋章
证书
证书查询 >
能力值