re: 关于对佛教的一个看法 温少 2008-09-09 00:20
@我是尼采信徒，和你信仰不一样，观点也是完全不一样。
尼采的信徒不会追去你所说的平和！
re: 大家是否有更好的方法？ 温少 2008-09-09 00:19
@weidagang2046
看了你的实现，我以前用.NET 1.0的时候，还没有Activator.CreateInstance方法吧。
你的实现有一些问题：
1、线程安全问题。多个线程初始化调用NewInstance方法时有问题。
2、既然是SingleInstance，就不应该命名为NewInstance。叫做GetInstance也许更好一些，或者就是一个只有get的Property，如public T Instance {get;}
re: 小议ID生成算法 温少 2008-07-16 12:50
我所说的做法，每秒钟可以产生100万个ID。
@代码乱了
只保证getAndIncrement本身是原子的，如果调用了getAndIncrement之后，不支持回滚。
@蛙蛙池塘
这个图表看不懂，相信怎么说你也不会懂。。。。
re: 关于java、C#泛型的看法 温少 2007-11-19 12:29
@Big Blue
你说得对,C++编译后List<A>和List<B>是不同类型，这个Java的实现方式显然不同，但是说是运行时支持也不妥当。
re: 小议ID生成算法 温少 2007-11-18 14:59
@随风流月
采用方案2预先生成一批，以前就做过类似的事情，问题就是集群环境下麻烦，就算不是集群环境，多台机器开发，一起连同一个开发数据库时，也会很烦人。
@路西菲尔
加入我的技术群50388823，放在群共享里了 :)
re: 小议ID生成算法 温少 2007-11-17 03:44
SEED如果由一台集中服务器来分配，而且带上一个额外信息，例如central_server_id、request_host_id、seed_inc_id，就可以做到集中分配，做到完全的UUID效果。这个和域名分配的思路是一致的。
由于引入了central_server_id，就可以做到多台分配服务器，容错于是也能够做到了。
采用方案三的好处就是，可以使用一个LONG就足够存储数据了，初始时甚至采用INT就足够了。在数据关联较为复杂的时候，很多表的数据中，很大一部分就是ID，ID的大小占用数据空间的很大一部分，这一点我们深有体会。在实际应用中，用过GUID，深切感受到他的坏处。
re: 小议ID生成算法 温少 2007-11-16 10:52
@沙加
ID最好是INT，或者BIGINT，不要使字符串，否则占用的空间就是太大了！
re: 小议ID生成算法 温少 2007-11-16 10:37
@小生
你没认真想一下 :) SEED生成一次就可以了，程序启动时生成，然后一直使用。
re: 小议ID生成算法 温少 2007-11-16 10:24
回12楼
COMB的问题是太长，效率会很低。这个我们吃过亏！当数据量上百万过千万之后，你将会十分痛苦。。。。
re: 小议ID生成算法 温少 2007-11-16 10:23
@木野狐
如按你所说，可以手工插入ID到自增列，那么这个ID从何而来？:)
可以实现，但是文章中介绍的实现有可能不比Java那样原生支持的性能好。
这篇文章本身的一个目的是记录迁移过程的一个关键类而已。如果需要，可以给你一个迁移后的整个工程，很多类的实现会比你自己实现的cas数据结构要巧妙很多。
re: 小议ID生成算法 温少 2007-11-16 09:46
@预备役中尉
你文章中的COMB类型占用空间太多不可取。我们通常需要更短小更高效的ID，同时要求唯一，这两个需求是互相冲突的。方案三是一种比较好的兼顾两个需求的办法。
调用一个方法park，就让当前线程停下来，再调用一下unpark，就恢复运行。这的确是.NET Thread没有直接提供的！
@路西菲尔
这片文章提供所以移植的AtomicInteger不就是封装么？
re: 小议ID生成算法 温少 2007-11-16 09:39
@jillzhang
如果使用-分隔，就不是数字了，存储空间就会增大很多，效率也会下降。
@阿毅
本文只是提供思路，在实际的实现中，可以做到你所说的要求。包括SEED生成的唯一性保证，备份恢复，灾备等等。在SEED的生成方案可以做很多事情。
re: 小议ID生成算法 温少 2007-11-16 08:58
@银河
我也熟悉Oracle，文章草草写成，所以没写上Oracle的实现。毕竟Oracle的SEQUENCE是比较特别，和MySQL、SQL Server、Sybase不一样，DB的语法和MS SQL Server类似的。
@大石头
我和《广西科学院学报》没有任何关系。
@柳絮飞
你的方法不可靠
@thinkry
SELECT MIN(FValue) FROM T
DELETE FROM T WHERE FValue = @minValue
这种场景也适合使用CAS，比使用事务好得多！
re: Atlas 实现机制浅析 [1] 温少 2007-11-16 05:29
堕落啊，你竟然研究起AJAX了。。。。
re: 关于java、C#泛型的看法 温少 2007-11-16 04:14
@phalanger
这个问题真的要追究起来，也可以说我不熟悉的 :)
不过你回复中提到的，就是Andrei Alexandrescu所提倡的Compile-Time Assertion吧。以前曾经粗略看过《Morden C++ Design》，据说loki是一个实验性质的库，把模板的技巧发挥到极致，我没怎么用过，你可以说我不熟悉。
另外提醒你，不要用粤语的文字写东西发问！
@路西菲尔
当出现脏数据时，CAS失败，然后回退重来，这跟ReadWriteLock完全不是一回事。ReaderWriteLock哪里会有脏数据呢？加ReadLock时，不能获得WriteLock，哪里来的脏数据。
这两个的设计意图根本不同，怎么能扯到一起来！
最近做了一个模块ERP的编码规则实现，应用了CAS，另外也作了一份不使用CAS而是使用数据库事务实现的。
比较结果如下：
（以下用Trans表示显式使用数据库事务）
单线程环境，CAS比Trans稍快一丁点，作10000次测试的平均比较，大约是3.6:4.1的差距。性能相差大约10%左右。
10个线程环境：CAS比Trans要快的多，9倍至10倍的性能差距。
@pgmfan
你的说法太笼统了，而且有误导性，也可以说不太恰当。CAS只是在高度竞争的情况下才不会获得更好的性能，也就是循环时需要多次才能成功时，才不会获得更好的性能。
ReadWriteLock在Read的时候加共享ReadLock，必须所有的人释放了ReadLock之后才能获得WriteLock。这和CAS完全是两回事，所以我说你的理解不恰当！
@装配脑袋
如果从优美的角度来说，增加运算符重载的确更好，可这只是代码移植，就不必做这种事情了。
re: 关于java、C#泛型的看法 温少 2007-11-15 13:36
@徐少侠
和C++ Template相比，Java和C#的泛型是小儿科，但是还算简单实用。
C++ Template的模板参数可以是值、类型或者一个模板，而且支持递归推导，编译期计算能力强大无比，但是带来的复杂性也是巨大的。很多C++程序员都不喜欢复杂的模板特性，我的一些朋友就是这样，坚决不在项目中用这些东西。
re: 关于java、C#泛型的看法 温少 2007-11-15 13:30
我来解答一下木野狐的问题吧:
boost::Tuple的设计目的：从函数返回多个值，将多个相关类型组合起来，将值组合起来。装配脑袋这个实现估计就是仿boost::Tuple。什么应用场景呢？例如平时我们经常要用的就是Pair<First, Second>，但是Pair只能组合两个值或者类型，而Tuple则可以组合更多。
re: 关于java、C#泛型的看法 温少 2007-11-15 10:51
@装配脑袋
看来对C# 2.0的语法还是关注的少了 :)
关于addAll函数，我文章中描述的观点是不对的。但是关于super的描述还是恰当的 。
在C#中怎么实现这个呢？
public static <T> void sort(List<T> list, Comparator<? super T> c);
@路西菲尔
你的理解不恰当，lock-free又不是ReadWriteLock之类的东西，与读与写有什么关系呢？！
@阿福1
并发的两个问题：竞争和合作，锁就是解决竞争问题的，数据库的锁和进程的锁是一样的。
这个例子举得不够好，在一些需要状态同步的地方很有用。例如分布式工作流之类的。
在文中提到的场景才是真正有用的：
"update T set FState = xx where FState = xx"
@chenwf
1、必须要注意的一点，这是很老的文章，三年前。
2、sumtec的做法，性能不可能更好，因为需要数据拷贝。他回复中提到的做法，单线程下存在多余的操作，性能肯定低下，而且需要更多的内存。多线程下，这种做法不合适，也不安全的。
3、sumtec关于多线程下的观点很牵强。普通的hashtable在并发条件下，不能保证线程安全同时获得良好的性能。
4、现在流行的做法是使用专门的数据结构，例如Java SE 5.0之后提供的ConcurrentHashMap。
5、基于lock-free算法的HashTable已经出现了，这才是并发条件下最好解决方案的。
http://developers.sun.com/learning/javaoneonline/2007/pdf/TS-2862.pdf
re: 不要奢望.NET能够跨平台 温少 2007-06-11 22:21
这件事情发生了如同想像中的结局，他们公司放弃了mono，也放弃了.net和windows，选择java+debian linux。从一个平台转到另外一个平台是很痛苦的事情，但是他们已经下了决心。
OpenBSD有“连续4年未发现远程访问漏洞”，这个安全能力如何？
re: 写了一个Rijndael工具类 温少 2007-05-29 08:39
现在不需要了吧，java 5中就带了AES的实现
《查拉图斯特拉如是说》，此书常常放在枕头旁边，放在书桌上，常看，常思考。看得很慢，其中深奥使得我反复思考。
这是我些年来，所读的最有意义的一本书，阅读此书并认真思考，从中明白“我”的存在，明白人生的价值所在。
这个阅读手记，对《查拉图斯特拉如是说》一书评价很深刻，对我理解书中的一些内容很有帮助，所以转载于此。
@kabell
你太强了，居然来了个巨长回复，word文字统计结果显示，有3500多字。
你的回复很合我意，我为此打开了允许匿名评论，欢迎你补贴其上。
re: 关于Java线程的实现 温少 2007-05-12 08:47
已经查过相关资料，Linux 2.6内核的pthread实现为NPTL，和内核线程的映射是一对一。之前的Linux threads也是。
re: 写了一个PPT，用于公司内部培训 温少 2007-05-09 07:15
增加了一些内容。其中图示还欠缺，由于图示工作量很大，一时难以补全，慢慢来吧。
目前版本2007-5-9，更新日期和版本日期相同，已下载的朋友，请重新下载。
曾经一度很喜欢mono，但觉得Mono不可能取得成功。Mono的出现，只会导致.NET阵营的混乱。
Microsoft提供的.NET类库，相当部分都是Windows API的简单封装。而且Microsoft只提供很少部分标准化，其他部分没有明确的规范。Mono在兼容问题将陷入很大的麻烦，在Windows Form、System.Threading、System.EnterpriseServices等。
Mono肯定做不了全面兼容，如果另起炉灶，产生一套新的库。这会产生混乱。
re: 不要奢望.NET能够跨平台 温少 2007-04-30 07:20
昨天了解了一下，他们的产品原来是.NET WinForm程序，在Windows XP下相当稳定，移植至fedora + mono时，产生频繁的进程假死想象，至今无法解决。
Linux下很多桌面程序都有进程假死现象，包括Firefox的某些版本。
印象中记得Mono下的WinForm实现，产生多次重大变化，摇摆不定。
re: 精巧好用的DelayQueue 温少 2007-04-29 22:48
@Base
原来文章中有DelayItem的，昨天加入一些内容时，不小心把DelayItem部分的代码删除了。现已经补上，请看正文。
re: 网络用语收集 温少 2007-04-28 21:28
re: 精巧好用的DelayQueue 温少 2007-04-28 18:58
修改了一下：
1、增加了对DelayQueue组成的讲解
2、把例子中用到的apache commons logging改为java.util.logging。
@随风流月
看小朋友这么勤快，我就解答你一次吧。
我2000年底就开始学习.NET了，工作后也是使用.NET开发，一直到2003年。算是微软在中国的首批.NET程序员了。曾经花过三个月的业余时间不借助工具反编译ASP .NET（当时还没有好用的.NET反编译工具），挨个学Quick Start，一遍又一遍看文档。算是刻苦和努力的。在.NET下的工作经验和对.NET平台的认知，应该比很多人对我的认知多得多。
回想起来，那段日子的学习效率并不高，主要原因是微软提供的资料有限，不提供源码，也没有良好的编程社区环境。现在社区环境比以前好了一些，但还是不够，社区并没有产生优秀开源库。其他方面的问题依旧。从长期学习技术的角度来看，学习.NET，不是一个好选择。
你还很小，学习技术不必要有很强的功利性。微软的东西入门简单，也许适合小朋友。但以后你想深入一步时，可能需要耗费更多的时间才能够达到。
放弃.NET吧，学习Java，将会给你带来一个更酷更广阔的技术天地。
@Dflying Chen
看了一下你的博客，看到你是做翻译技术书籍滴，对中国软件业有贡献啊。偶给你一个建议，翻译就好了，不要试图自己写书。