|
锁定老帖子 主题：讨论－－关于开发邮箱系统
该帖已经被评为精华帖
|
|
|---|---|
| 作者 | 正文 |
|
发表时间：2006-01-29
引用 这段代码你想证明什么呢？runtest()+sleep(1000*10)的速度？runtest不过是开启100个thread的速度罢了，这个时间除count的有什么意义呢?另外x.running=false，你能保证所有的thread瞬时退出，所有count计数完毕? runTest()创建100个线程，每个线程对计数器加1后唤醒另一个线程，然后自己进入等待状态。count即是线程的切换次数。 x.running=false不能保证线程退出，只是让线程不继续进行计数，另外先停止计数再停止计时准确些。 结果： time = 10124 ms count = 217760 count/time = 21/ms |
| 返回顶楼 | |
|
发表时间：2006-01-29
你测试的仅仅是，thread context 切换.这种,纯粹测试context 切换是没有意义的。这里有两个关键问题，第一个问题是在大运算量大并发下，一次同步，一次等待是需要尝试多次才会成功，这就是所谓的线程壅塞，在壅塞的情况下context的切换完全没有那么容易。你可以去看看Edward G. Bradford 对linux和Windows的线程模型分析。
http://www-128.ibm.com/developerworks/cn/linux/sdk/rt/part9/ 引用 这种特殊的测试不能代表很多（如果有）实际的情况。它的确清楚地显示了每种操作系统的上下文切换速度可能具有的一些局限........毕竟，如果不完成一些实际工作，上下文切换没有任何意义
http://www-128.ibm.com/developerworks/cn/linux/sdk/rt/part10/ 引用 当它成功地获得一个锁，它释放自己的锁，唤醒前一个线程，这个线程也做同样的事。因为区域中只有一个额外锁，所以每次只能运行一个线程。大多数获得锁的尝试都会引起操作系统中的阻塞。
使用一个额外锁时，我们的测量结果显示 Windows 2000 中每个线程完成 50000 次锁定／解锁调用平均花费 8.4 秒。Linux 中的平均时间为 12.3 秒。Windows 和 Linux 的最长时间和最短时间平均都在 10 毫秒以内 第二个问题是，带负载的context switch并不是简单的switch开销。这点在Lembench的文档里说的很清楚。 http://www.bitmover.com/lmbench/lat_ctx.8.html 引用 The effect is that both the data and the instruction cache get polluted by some amount before the token is passed on. The data cache gets polluted by approximately the process ``size''. The instruction cache gets polluted by a constant amount, approximately 2.7 thousand instructions. 带负载的情况下，前一个context的数据和指令缓存会受到，后面的一个context的污染。数据缓存的污染取决于你的当前thread或者process的尺度，指令缓存污染在linux下面是一个定值2.7k个指令。 因此 引用 The context switch times go up because a context switch is defined as the switch time plus the time it takes to restore all of the process state, including cache state. This means that the switch includes the time for the cache misses on larger processes.
切换开销是取决于切换时间和大尺寸的线程上的数据cache的命中率。 你的process或者thread的尺寸越大，cache就越容易miss. |
| 返回顶楼 | |
|
发表时间：2006-01-30
不错，谢谢T1指点！
详细看了Edward Bradford分析问题主要是在lock上. 在JDK1.5中提供了新的lock机制，相比synchronized在高争用的情况下有明显的提升。 见http://www-128.ibm.com/developerworks/cn/java/j-jtp10264/?ca=dwcn-newsletter-java 在下面这篇谈到了未来6.0对同步的优化。 http://www-128.ibm.com/developerworks/cn/java/j-jtp10185/ |
| 返回顶楼 | |
|
发表时间：2006-01-30
nihongye 写道 不错，谢谢T1指点！
详细看了Edward Bradford分析问题主要是在lock上. 在JDK1.5中提供了新的lock机制，相比synchronized在高争用的情况下有明显的提升。 见http://www-128.ibm.com/developerworks/cn/java/j-jtp10264/?ca=dwcn-newsletter-java 在下面这篇谈到了未来6.0对同步的优化。 http://www-128.ibm.com/developerworks/cn/java/j-jtp10185/ ReentrantLock，本质上还是一个mutex，与synchornized在量上并没有本质区别，只是提供了原来mutex有而synchornized没有的功能.个人认为，这个东西用处并不大，反而由于java缺乏RAII以及Java程序员习惯于依赖VM回收的习惯导致大量的死锁，倒锁，递归锁的出现。不过Java 1.5的同步包的确提供了很多高性能的同步方式。比如automatic的CAS算法能够跨平台的作lock-free同步,这点非常不错。但是无论怎么从平台级别提高性能只要有GC存在，Java程序员不摆脱小并发量下的经典编程习惯(比如说很多Java程序员都不知道new操作符内部同样有锁存在),Java仍然不适合于电信级别的应用。 这方面.Net/python的设计好的多,主要是它能通过简单的接口把性能敏感部分分离到c++去做，现在的很多处于实验阶段的RTJAVA也是走这条路只不过RTJAVA把C++的特性封装成vm特性，比如无堆内存，实时线程等等，而J2SE这方面Jni一来接口复杂二来Java历来的平台无关性的宣传使得程序员难以接受他。 在我看来基于VM的现代编程语言，参与到高并发量的应用唯一可行的方法是AS400那样的本地代码化。 |
| 返回顶楼 | |
|
发表时间：2006-01-31
5.0里的ReentrantLock里在比较并交换 (CAS)的基础上实现了spinlock,并不是依赖于操作系统的mutex
|
| 返回顶楼 | |
|
发表时间：2006-01-31
Trustno1 写道 谁说没有关系,一来现在电信最火的是NGI,NGN,目标就是VOBB,把所有的语音服务构架在Broad Band上面.他最大的卖点就是用软件替代电路交换降低成本。在这里就是软件人员的天下,现在所有的原来的大的硬件厂商像Nortel,Avaya,Nokia都把他们的交换机往IP迁移。二来，即便是TMD交换机他也只负责交换而已，但是如何处理所有的话路的信息，统计，如何监控交换机的工作状态，等等都是应用层面的事情，虽然这些地方的实时性要求比交换路由低一些，但也是需要进行实时的端到端的管理，这同样不是企业级的设计能应付的. T1出山之贴,留一名. 貌似现在我们公司就是让大家疯狂的将case从R99转换到R4的VoIP结构上去呀 |
| 返回顶楼 | |
|
发表时间：2006-02-01
:idea:
|
| 返回顶楼 | |
|
发表时间：2006-02-13
没必要，那么多现成的，
而且做起来相当复杂(当然，仅仅实现功能还是相当简单的)，没有几年工夫，估计难稳定下来。 |
| 返回顶楼 | |
|
发表时间：2006-03-07
http://www.fj133165.com
使用python＋java开发的福建联通如意邮箱系统 |
| 返回顶楼 | |
