g*****g
发帖数: 34805 | 1 按说不会，要吗断电要吗不断电。如果内存有问题，你的程序会
崩溃，不只是死锁那么简单。 |
|
x****u
发帖数: 44466 | 2 一般情况下遇到锁阻塞是正常思路，OS设计者的苦心也在这。如果类没有逻辑错误，也
不会因为阻塞一小会而死锁。
策略应该分读者优先和写者优先两类考虑吧，一个mutex怕是不够？去年搞过一个对性
能极度敏感的map，现在记不清楚了。 |
|
b*****d
发帖数: 23 | 3 比如 如何 防止死锁， 多线程之间的 同步，
process 的memeory layout，
process 和 thread 的关系 之类的问题。
哪里可以找到比较全的书啊。
看了本 modern operating system， 讲了一点 但是没有讲全。
而且似乎太低层了， 什么 Kernel mode, user mode, PSW 之类。
虽有用， 但是 还不够， 也用不上啊。。。 |
|
s*******e
发帖数: 664 | 4 ☆─────────────────────────────────────☆
dawangzi (大王子*催贝卡) 于 (Fri Nov 20 19:19:29 2009, 美东) 提到:
WC,做了好几年VC,这才意识到,太颓了.
还请大侠Confirm:
//同一线程里的两个消息响应函数
ON_MESSAGE01()
{
PostMessage(02);//没用的,BlahBlah需执行完,不算嵌套
SendMessage(02);//更没用,死锁
BlahBlah
}
ON_MESSAGE02()
{
WahtEver
}
难道这是真的吗?为什么呢?
☆─────────────────────────────────────☆
microbe (纵使相逢应不识) 于 (Fri Nov 20 19:32:08 2009, 美东) 提到:
SendMessage waits for the response, of course it will deadlock since there
is only one UI thread.
☆──────────── |
|
|
d******i
发帖数: 7160 | 6
A和B的Wait/SetEvent的顺序是不同的，和给的例子不一样啊。 |
|
b********n
发帖数: 609 | 7 那个a和b的event是怎么发的，确定两个thread总能接到event么？有一个接不到就僵在
那里了。 |
|
d******i
发帖数: 7160 | 8 就是 setevent 成Signaled 状态啊。
按说A被Block在Wait(b)时定然已经Signal(a)了，那么为什么B还会被Block在Wait(a)
上呢？
不懂啊。 |
|
b********n
发帖数: 609 | 9 你的code不全没法判断，比如a，b有没有被lock。 |
|
d****p
发帖数: 685 | 10 optimization is on?
Sometime statements swapped in generated code. |
|
b********n
发帖数: 609 | 11 没听说过optimization能产生deadlock。 |
|
|
d******i
发帖数: 7160 | 13 可能是Signal了以后没有线程在WFSO的问题。
有两种说法莫终于是：
一种说如果没人在等就白Signal了，
另一种说没问题。
各位以为如何？ |
|
b********n
发帖数: 609 | 14 我不搞Windows编程，反正Linux下如果signal了没有thread在等，肯定是白费了，
Windows应该也是一样。 |
|
d******i
发帖数: 7160 | 15 不是吧。
只知道palseEvent会自动reset(不管有没有谁在等)，没听说SetEvent也会啊。
可是侯捷翻的那本多线程的书是这么说的。
不懂了。 |
|
b********n
发帖数: 609 | 16 我说过我不搞Windows，你attach debugger看一下不就完了。 |
|
b*******s
发帖数: 5216 | 17
没错，POSIX threading就是这样的，没人在等的话signal也白费了
解决之一就是wait不要傻等，给个timeout
或者想办法保证signal之前一定wait |
|
a****l
发帖数: 8211 | 18 您给的例子不是在一个while的loop里吗?既然是while,循环不就一样了吗?
while (1) {A;B}的执行是 A,B,A,B,A,B
差一位不就是B,A,B,A,B,A,
就等于 while (1) {B,A}吗?
其实问题就是差了一位. |
|
d******i
发帖数: 7160 | 19 说的好。
问题就是这一位是
永远不可能
差出来的 |
|
e****d
发帖数: 895 | 20 CPU & compiler optimization could reorder them, but not in this case though. |
|
a****l
发帖数: 8211 | 21 其实楼上不已经解释过为什么是可能差出这一位的了吗?你自己仔细想想,为什么系统的
设计会导致能差这一位还是很有道理的. |
|
d**d
发帖数: 389 | 22 两个线程A 和 B,现有一个信号量s。
thread model like this
s=semaphore_create(1);
in thread A
semaphore_wait(s);
{
do_some_thing_here;
wait until STATUS in thread B is TRUE;
continue_do_something;
}
semaphore_signal(s);
in thread B:
semaphore_wait(s);
{
do_some_thing_here;
set STATUS to TRUE;
continue_do_something;
}
semaphore_signal(s);
问题是：
in thread A "wait until STATUS in thread B is TRUE;", 如果用另外一个新的信号量，那么肯定是死锁。请问有没有什么好的解决办法让thread A一直等到STATUS被thread B设成 TRUE。
非常感谢！！！ |
|
S****z
发帖数: 666 | 23 s=2?
信号量，那么肯定是死锁。请问有没有什么好的解决办法让thread A一直等到STATUS被
thread B设成 TRUE。 |
|
s*****n
发帖数: 5488 | 24 不是dump 了嘛？注意要等cpu没太多活动，但是心痛没有反应时取得。
然后windbg 打开dump file,!threads, !clrstack一个个看吧.
懒惰的话， 如果是C code, windbg直接支持。 c#网上应该有windbg的死锁检查的。自
己赵忠吧。 |
|
L******e
发帖数: 136 | 25 问题是，很有可能是数据库的Lock和C#的Lock相互死锁，Dump只能查c#Lock吧？ |
|
s*****n
发帖数: 5488 | 26 unmanageed code.被锁的线程只能是
waitforSingle/multipleOjbect enterCritialSection on top of stack.
留心这些线程。
!CS?记不清楚了，查查手册可以找到关于死锁的。可以列出所有critricalsections.很
容易看到里面挂着多少等待线程。
一句话，dump is your friend.慢慢查吧。你需要系统的symbols. |
|
x****u
发帖数: 44466 | 27 你少见多怪了。
用仿真器跑嵌入式内核，最后发现CPU在几个状态内循环，内存无变化的就是死锁了，
俗称跑飞了。这是常见操作。
problem |
|
s*w
发帖数: 729 | 28 又琢磨了两天，看了不少相关东西，终于搞定了，觉得自己对这个多线程的理解加强了
很多。思考比单纯的看人说原理更刻骨铭心。
这个问题我设计的用一个 producer 多个 consumer 的架构，上个版本的是两头用
condition_variable, 一个通知 producer 有空间了开始干活生产，另一个通知
consumer 有库存了开始消费。参见上篇里面的 wait 和 notify_all,notify_one 语
句。 这个思路对于单 producer 单 consumer 没问题，可是不适用于 多 consumer.
因为所有的 consumer 可能同时睡觉（没空存），同时醒来（有库存）,结果只有一个
能抢占mutex(拿到库存)，其他的只好继续睡觉（while 循环 wait）. 如果无限制的
生产下去，每个睡觉的都有机会醒来干活。可是在有限生产的情况下，producer 干完
活了后，总有睡觉的 consumer 无人唤醒导致死锁。解决的办法就是用 non-block
的 try_lock, lock 不上就返回 false，这样有机会检查是否需要(还在生产或是有
... 阅读全帖 |
|
|
|
b*******s
发帖数: 5216 | 31 死锁看你怎么设计了，四条件破坏其一就行，c++多线程的困难之处我觉得不是这个 |
|
z****e
发帖数: 54598 | 32 是数据处理上的争抢
比如a-b-c线路
你要定这条线路，然后锁住了b，等a和c
古德霸也要定，锁住了a，等b和c
我也要定，锁住了c，等a和b
怎么办？
一般情况下直接超时踢出去
但是并发量太大，会导致几乎每一次都是死锁 |
|
a*****e
发帖数: 1700 | 33 你这段 psuedo code 正好说明 lock 机制不适合从小部件拼装组合大部件。比如这段
封装起来成一个函数 extract(x, A, B)，看似没问题吧？结果用户在不同的两个线程里
用到了 extract(x, a, b) 和 extract(y, b, a)，你就死锁啦！
而且 delete 和 insert 的具体实现也不一定非要 whole table lock 不可。
后面那个 atomic 的写法显然需要 global lock，正确性是有了，但是没效率。 |
|
T********i
发帖数: 2416 | 34 多谢你花时间和精力在上面。衷心希望你这样的网友能成为这个板上的中坚力量。
其实座位最好占用至少一个integer而不是一个bit。多个cpu core可以同时死锁通过
compare and exchange cpu指令抢票。整个核心可以做成完全无锁的，而且用java之类
的语言也能实现。 |
|
g*****g
发帖数: 34805 | 35 是你没明白DB transaction怎么工作的吧。比如说50%的人一次只买一张票，他们就没
问题了，春运放票往返也没法同时买，我们暂时不考虑。另外50%的人需要买联程票，
简单点一次买两张，任意。这就是个transaction，只要是一个单子，要吗都买到，要
吗都买不到，这叫DB atomic transaction。
如果这两段票在同一个数据库里，就是一个普通的数据库transaction，如果不在，就
要distributed transaction。如果可以完美分库，那就没有distributed transaction
。所有的流量可以近乎平均的分到各个数据库里。从而降低了单个数据库压力。
至于查询，完全是cache的。不会Hit 数据库。我能做到的只能跟你说1秒以前，或者10
秒以前，数据库里还有几张票。你下单的时候看到有票，我不能保证你下单就能买到。
Transaction做的是，把两段的计数器都锁了，然后减一。如果锁不到，就等。分布式
数据库的类库有避免死锁的支持，比如都按DB ID大小同向锁。
这样说明白了没有？ |
|
n****1
发帖数: 1136 | 36 我记得二爷是js/closure一脉的吧
对我来说,Pure FP最大的好处就是very easy to reason the program. 从人的角度来
讲,只要你读懂了代码,基本不会有啥pitfall,所以读完代码就基本可以放心了. 而c/
java则不同,除了读懂代码本身,还要考虑各种乱七八糟的同步,死锁.
从机器的角度来讲,easy to reason的结果是compiler capture most error, 而
Runtime error的可能性极小. 所以pure FP省去了很多debug的时间. 听说很多语言要
花80%的时间来debug,太痛苦了.
而js/closure完全反其道而行之, 不仅是mutable,而且是duck typing, 程序几乎无法
reason, 结果就是all bug is runtime bug. 与其这样,我还不如用java. |
|
T*****e
发帖数: 361 | 37 你这个架构跟goodbug说的感觉差不多，特别是非实时订票买票以及订票服务器按车次
横向分布两个方面。
对于余票查询，这个好像跟goodbug的方案有差别。goodbug的方案应该是实时的。其实
可以根据数据量的不同，可以把余票查询分为两类。
一类是来自车票查询网站的用户余票查询。这个可以从余票服务器（或订票服务器）汇
总后的snapshot服务器来查询，这个应该非常快，可以做到结果正确但非实时，也就是
说余票查询的结果是过去不久前的结果，而非此时此刻。估计你说的也是这个意思吧。
个人感觉这样做没啥大问题，毕竟余票查询只是订票的参考。
你的订票服务器可能叫单票服务器更清楚些。单票服务器除了余票外可能还需要维护单
票请求队列，通过队列来确定下一个获得暂时订票的订单。未被确认的暂时订票在一定
时间后可以转给下一个订单，防止死锁。
另外一类余票查询来自订票系统（订票综合服务器）。这个可以直接从单票服务器及其
replicas上查询。订票则走主单票服务器。这个其实是真正的用户订票处理服务器，用
来接收、处理和维护从订票网站传来的各种订单。所有订单都分解为单票请求发给单票
服务器，在获得暂时订票... 阅读全帖 |
|
n****1
发帖数: 1136 | 38 你指哪方面问题?
核心单线程不用考虑上锁, 自然没死锁, 不用管同步. 如果一秒钟只需要处理一个
request, 8086的cpu都没问题.
可是目前的数据量, 你跑单线程是会socket buffer overflow的, 没准还能把cpu烧坏.
现在系统里有多个要处理的问题: IO性能, 内存大小, cpu性能.
你搞in ram memory, 上大内存, 我都不反对, 可这只解决前两个问题. CPU要求高是因
为票的分配与组合逻辑本身非常复杂, 单线程受不了, 单机多线程也够呛, 最后只能上
多机. |
|
n****1
发帖数: 1136 | 39 弱耦合可以像goodbug说的那样分库, 怎么分的话需要分析历史春运数据. 分好了死锁
问题就没啥大不了的了. 反正有一年的时间做规划, 分得再细都行.
如果你的方案无法实时分配座位, 我只能彻底推翻你的方案支持上机群了, 没准这种精
心设计的机群还能保证实时回复余票+实时分配座位. |
|
j********p
发帖数: 9680 | 40 应用程序级别,考虑异步队列处理是对的.
数据库级别,考虑分布式数据库,把重要的Table尽量拆分到性能比较强的机器上.
如果有必要的话,对query进行必要的简化和优化.
设置脏读是有必要的.不要动不动就锁表长时间.
死锁一定要避免.
对实时的理解,在客户和设计者来说概念是不一样的.
在设计者角度来说,只要把整个过程的时间控制在一个范围内,
对于客户,就是实时的. |
|
|
b*******s
发帖数: 5216 | 42 又来你老了，你多老了？顺序拿锁这是最基本的知识，就像没有干预就无法破坏锁定才
叫死锁一样，都是最最基本的东西 |
|
