这是一个创建于 3964 天前的主题，其中的信息可能已经有所发展或是发生改变。
 |
1
rockpine 2014-01-05 14:58:00 +08:00
每次看到你得头像，都会想起日本电影《死亡笔记》中的L
|
 |
2
moroumo 2014-01-05 14:59:02 +08:00
这个的确是我以前的梦想
|
 |
3
efi 2014-01-05 14:59:45 +08:00
The kernel community has never really had to worry about attracting new developers, but new kernel developers may become harder to find in 2014. Kernel development is getting harder to get into, and the level of contributions from unpaid developers has been falling for years. An environment where an understanding of Documentation/memory-barriers.txt is increasingly necessary is going to be off-putting for a lot of potential developers, who may just decide to focus on JavaScript applications instead.
http://lwn.net/Articles/578124/ |
 |
4
Tonn 2014-01-05 15:13:11 +08:00
学过的简单，没学过的觉得难，虽然许多时候用不着，但memory barrier以及相关的原子操作问题确实可以搞死一批人。
最近在看kernel网站的perfbook很不错： https://www.kernel.org/pub/linux/kernel/people/paulmck/perfbook/perfbook.html |
|
5
efi 2014-01-05 17:05:20 +08:00
|
 |
8
cyfdecyf 2014-01-06 11:21:02 +08:00
@Tonn @efi 这东西学起来也不简单。想要弄清楚 reorder 如何发生得了解 CPU store buffer, invalidate queue, cache coherence protocol 之类的概念。仅仅知道怎样用 memory barrier 阻止 reorder 也不会知道 barrier 指令最好应该放在哪里，我有过一个程序因为插入 barrier 指令位置的差别有 5% 的性能差异。
好在写用户态程序多数时候也不用关心这个，除非是实现 ad hoc 的同步机制和提供并发数据结构，用别人实现好的同步机制一般已经把这些问题隐藏掉了。 当然坑依然存在，开始学 Go 的时候觉得并发编程终于简单了很多，但看过 Go Memory Model 之后发现有了语言抽象之后只不过把这种坑发生的层次提高到语言级别，一不小心还是会踩到。 |
Select Language