我一定是渣, 虚心向程序员帝们请教, 开发中如果避免使用debugger -- 请KA娃和yuba务必发言

kawara

原帖由 大饼 于 2010-10-19 19:49 发表

木有class。
不是java，纯C。
一坨一坨的驱动，动不动就几十个c文件。
原来的IDE都是c++写的，现在全都改成eclipse了

那我们怎么会知道，我们是java developer

[ 本帖最后由 kawara 于 2010-10-19 20:06 编辑 ]

NoChoice

IncrediBuild

大饼

原帖由 kawara 于 2010-10-19 19:54 发表
那我们怎么会知道，我们是java developer

啊,原来大家一坨一坨的都是用JVM的,没有开发JVM的

yuba

用命令行编编试试呢？

乱码

有关.net是否用到multiple core，读了几篇文章，觉得我开始的理解（总是在一个core上run的概念不准确），schedule task on different cpu应该是os的事情,我们不用关心，有一个core它就用一个，有N个core可能都会用上.

http://stackoverflow.com/questio ... different-cpu-cores

kawara

原帖由 乱码 于 2010-10-19 22:21 发表
有关.net是否用到multiple core，读了几篇文章，觉得我开始的理解（总是在一个core上run的概念不准确），schedule task on different cpu应该是os的事情,我们不用关心，有一个core它就用一个，有N个core可能都会用上.

http://stac ...

貌似跟java一样。那个人提问如何分配线程，别人告诉他不需操心，操作系统会搞定。

但是那个人的程序已经是多线程的。

大饼

原帖由 yuba 于 2010-10-19 20:40 发表
用命令行编编试试呢？

俺现在只知道改 eclipse.ini里面的内存设置。还有别的法子吗？

乱码

原帖由 kawara 于 2010-10-19 22:28 发表

貌似跟java一样。那个人提问如何分配线程，别人告诉他不需操心，操作系统会搞定。

但是那个人的程序已经是多线程的。

是啊，系统给thread分配core，不用操心这个。

不过也可以通过programming的方式来指定processor的affinity，或者runtime通过task manager来做，不过这种方式很少见，除非有很特殊的原因。

iami

cdfei

主要是你那两核太强了。

yuba

原帖由 大饼 于 2010-10-19 22:40 发表
俺现在只知道改 eclipse.ini里面的内存设置。还有别的法子吗？

不像内存不够用，能用make在命令行下编译吗？

zn7726

你们太牛了 ... 都跑到多线程 vs 多核cpu 上来了.

dalaohu

原帖由 winsome 于 2010-10-19 19:24 发表



？？？

我说的是在设计的时候除非性能瓶颈，否则尽量不要选择多线程

当然要走多线程，

UI main thread, worker on another thread. 这是最基本的美德。

kawara

都乱了。要不讨论点轻松的，比如说脚本

这里还是做界面的程序员多

[ 本帖最后由 kawara 于 2010-10-19 23:44 编辑 ]

iami

去tmd concurrent programming当年可把我给折腾的半死.
到现在我还对它念念有词！

kawara

原帖由 iami 于 2010-10-19 23:44 发表
去tmd concurrent programming当年可把我给折腾的半死.
到现在我还对它念念有词！

哦？我还以为dotnet没有多线程呢。大咪咪挺厉害

考你一个，啥叫livelock?举个例子

[ 本帖最后由 kawara 于 2010-10-19 23:52 编辑 ]

澳贼

原帖由 kawara 于 2010-10-19 23:50 发表

哦？我还以为dotnet没有多线程呢。

考你一个，啥叫livelock?举个例子

骨骼说。
A LiveLock is the same as a DeadLock, except that processes are not blocked forever, they are being processed constantly by the CPU。。。。。。。。。。。

dalaohu

服务端更要做多线程， 大批量，长时间的处理 我全部开在另外的线程上。
这样service就很responsive.

iami

原帖由 kawara 于 2010-10-19 11:50 PM 发表

哦？我还以为dotnet没有多线程呢。大咪咪挺厉害

考你一个，啥叫livelock?举个例子

你这不是哪壶不开提哪壶嘛。

deadlock是死的，大家都在等。
livelock是活的，大家都在动。

livelock的例子，我瞎说一个哈，错了别怪我误导，还一定要纠正我啊

跑两个线程，每个线程都设置成去access两个resources中的一个,
如果发现一个resource被accessed就去access another resource.

现在，thread A 和B同时access resourceA的时候，发现A已经not available(有点像泡妞)，
然后同时放弃A，同时奔向resource B.结果发现B也不available了，

于是thread A,B又返回去access resource A,然后resource B......

我忘记solution了，好像是规定resource一次只能接一个客人。就能避免这个情况的发生。
当时学的郁闷死了。如果不是当时老师说实际产品，像corba这些在底层已经会take care这些东西，我真不知道是不是该退学了


学的时候是用java做功课。livelock提到过，但是功课似乎没有做到过。已经模糊了。

小马识途

和我理解的一样，例子不太贴切，应该改为：
两男去泡一个妞A，两人总是同时起身，同时搭讪，结果妞A一个也听不清，造成妞A这个资源永远not available，解决方法是，要求两男同一时间只能有一个和妞搭讪。

顺便问一下，你们怎么都那么晚睡，K哥居然6点就起来了，平时都怎么补的？

乱码

原帖由 dalaohu 于 2010-10-19 23:58 发表
服务端更要做多线程， 大批量，长时间的处理 我全部开在另外的线程上。
这样service就很responsive.

从理论说是这样，关键是iis接受request，自己从thread pool拿一个独立的thread来处理这个request，如果你有很大的i/o,你可以自己再从thread pool拿thread去干这事，然后用callback，关键是一旦把任务delegate给其他的thread,处理这个request的main thread在这个期间做什么? 系统回收它，用来处理其他的request？一旦回收之后，context info都全部丢失，写response几乎都不可能。我猜这个main thread还是在干等，除非它可以有2个以上大的i/o operation,它可以做2个child threading的coordinator.

现在我们所有logic都是single thread,我在想一个solution让它"并行",几年前我记得1.1好像有个置位的操作，说明这个operation完成了，如果有几个thread的operation，都会置自己的位（0变1），一旦全变1，说明parelle的行为全部完成，可以给user response了.

其中的细节完全忘掉了。

nodejs这点就做得很好，就用一个main thread来响应request，而不是开始就用新的thread，任何大i/o operation，都去thread pool拿thread,用callback，它server side资源耗用很低，平平的一条线，比起来apache的resource曲线随着request的增多就很吓人，很sharp的线。

[ 本帖最后由 乱码 于 2010-10-20 09:46 编辑 ]

dalaohu

簡單的說， 把不同的計算分到不同的thread上能讓你的system 更responsive.

把每個計算用多核parallel 來處理，能讓計算更快的完成。

dalaohu

這跟什麼前台，後台無關，是一個通用的設計理念。覆蓋了整個系統。

dalaohu

livelock 是deadlock的副剷品。你都可以不用知道livelock， 把deadlock解決了就沒有livelock了。

通常情況下deadlock是有SQL的transaction造成的。沒有什麼通用的解決方法，都要等情況發生了才具體研究。

以前的一個項目裡發生過， 那個項目裡是一大幫.net 的super star, 也都好幾週一籌莫展。

kawara

经典的解释是两个人约好比如说在某购物中心见面，甲去了麦当劳，已去了肯德基。互相联系后，甲去肯德基找乙，乙去麦当劳找甲，反复折腾，总是见不着。

具体的例子是什么呢？

kr2000

这帖技术含量好高

dalaohu

原帖由 kawara 于 2010-10-20 10:19 发表
经典的解释是两个人约好比如说在某购物中心见面，甲去了麦当劳，已去了肯德基。互相联系后，甲去肯德基找乙，乙去麦当劳找甲，反复折腾，总是见不着。

具体的例子是什么呢？ ...

具體例子不重要， deadlock 發生在不同的情況下。 通常來說就是2 個單獨的process 去要統一個resource.
deadlock 不可能完全避免，只能把它做到最小化。

你可以在發request 的client上做點工作。要讓client handle deadlock.
比如設timeout 限制，重發request. 或introduce a message queue system.

或把resource 做成instance 形式， 把transaction 加在 client request level。

這些到要看具體的問題情況了。

小马识途

俺来造一个例子，瞎造的，勿当真
两个系统A和B，都管理客户信息。当要更新某个customer的时候，A先在local把这个Customer给占了，然后再通知B，如果B同时也要更新同一个Customer，B也正好在local已经把这个Customer给占了，正在通知A，那么两个request就会同时返回false，等一定的时间后（假设这个时间间隔一样），再来一次，一直循环下去。

Dan.and.Andy

原帖由 小马识途 于 2010-10-20 10:49 发表
俺来造一个例子，瞎造的，勿当真
两个系统A和B，都管理客户信息。当要更新某个customer的时候，A先在local把这个Customer给占了，然后再通知B，如果B同时也要更新同一个Customer，B也正好在local已经把这个Customer给占了，正在通知A ...

您这是个很普通的concurrency问题, 任何一个数据库产品都很好的解决了这个问题. 不关多线程的事

小马识途

livelock 不就属于concurrency问题吗？