2011-06-03

前天买了一本好书,〈The Art of Multiprocessor Programming〉。这名字挺俗的,但是内容却是很好。整本书一分为二,上半部是理论,下半部是实际算法。讲理论的时候不忘记给出实际的能工作的 JAVA 代码,volatile这样的关键字也用的是恰到好处。我看的慢,也就刚看到第二章。这一章在讲啥呢?在帮我回答之前我的leader(LCH)给我们出的一个自测题:自己实现一个互斥锁,不使用kernel的任何系统调用。这不仅要脑袋特别灵活,能巧妙的设计出一中locking protocol,而且要求对processor或者language的memory model非常熟悉。

我有个朋友把微博比做车站,公交车站或者地铁站或者火车站,我觉得像极了。人来人往,吵杂,烦躁,疲惫。大量的信息不通过大脑直接点转发。看见一条消息,写下它的评论,中间也就间隔2-3秒的时间。我今天在微博上问:“对于一个key-value数据库来说,Repeatable Read和Serializable这两种隔离度的区别是什么?我一直不明白,key-value数据库怎么会有幻影呢”。后面的评论五花八门。大部分人不会去回忆SQL92标准中4种隔离度到底是什么?然后一些资深人士就开始讲数据库是如何实现事务的,我看的云里雾里的,不敢说他对,也不敢说他不对。直到最后经某人在微博上提醒,“对于支持range query的key-value store”可能存在幻读的问题。然后我去比较了一下Berkeley DB C版本和JAVA版的接口之后,发现JAVA版提供了根据key的range query的功能,我才豁然明白了。

拿JAVA来说,假如当初是你,你来设计这门语言,那么为什么选用这样的memory model,就是一个足够难以回答的问题。当设计一个底层平台的时候,这些形而上的问题是最最难解决的问题。比如Berkeley DB C版本的有3种不同的事务隔离度,而JAVA版本则有4种?SQL92标准的全部4种? 最难的是发明一种新的编程模型,还能被广泛接受。这方面我十分的佩服LCH。

拿JAVA写大型数据库应用的时候有一个弊病,内存太大导致GC很慢。但是貌似这并不是没办法解决的问题。比如,最近看到一个database,采用软引用来管理cache,理由是gc的时候更容易。是吗?我怎么觉得软引用才是恶梦呢?但是我总觉得,一定能找到什么办法,能够把一个对象简单的标记为不可被回收,然后又在想扔掉的时候方便的把它扔到垃圾堆里。管理cache的代码占不到总代码的1%,它来做手动释放这样的事情就好了,其它的内存,还是像现在这样,自动GC,那该多好啊。这又涉及到我之前想了很久的那个问题了,假如一部分系统用C++实现,一部分用JAVA或者脚本。那么这个界限,划在哪里?数据库层?应用层?等等。

在家看了一部烂片,青蜂侠!

此博客中的热门博文

少写代码,多读别人写的代码

在windows下使用llvm+clang

tensorflow distributed runtime初窥