今天的两个收获--linux的特性和海森堡式错误-阿里云开发者社区

开发者社区> 开发与运维> 正文
登录阅读全文

今天的两个收获--linux的特性和海森堡式错误

简介:

今天我看了一个守护进程的man手册,加深了我对linux的理解,这个守护进程就是netplugd,它主要就是检测网络接口的状态,一旦一个网卡接口接通了,那么就会调用ifup,相反down掉了就会调用ifdown,这里涉及两个问题,第一,用户守护进程netplugd怎么检测到网络接口的状态;第二,用户进程netplug怎么知道检测到接口变化以后要怎么做。对于第一个问题,答案就是netlink套接字,内核肯定知道网络接口的实时状态,一旦知道了状态就会用netlink通知用户空间的netplugd守护进程,内核只管通知,而根本不管用户守护进程会怎么做,从而我们知道内核提供机制,而用户守护进程提供策略,对于第二个问题,答案就是配置文件,当守护进程netplugd接收到netlink的信息后,自己只管接收到而不管具体怎么做,它只是内核机制和真正策略的二传手,真正的策略需要配置文件来定义,它实际上调用了/etc/netplug.d/netplug脚本来执行策略,这里我们知道netplugd守护进程提供机制,而脚本配置文件提供策略。从而我总结出,在linux中,一般的内核机制都会存在一个用户进程,而一个用户进程一般都会有一个配置文件,分层次地体现机制和策略的思想,用户进程作为内核机制的策略和用户配置的机制相当于一个二传手存在。

接下来的第二个收获就是海森堡式错误,这是在内核邮件列表中的一个朋友的回复中学到的,有位朋友问wake_up和printk有什么关系?为什么他调用printk就可以正常执行,而不调用printk内核线程就会锁在那里,我感觉他肯定是在写代码时造成了终端的竞争,因为printk可能要用到终端打印,但是我还是感觉这二者不应该有什么实质性的关系的,后来另一位朋友发言了,这个论点十分精辟,他的回答如下:“海森堡形bug, 来自海森堡测不准原理 当你测试的时候就没有发生相应的bug。因为测试的代码带来一些时间的消耗, 内存/cache的副作用...等待 导致结果正确。50%是跟臆断代码执行的先后关系有关. printk() 仅仅是消耗了一些时间,

使得异步执行的语句的顺序跟你原来编码时臆想的一样, 结果就正确了.”有了这个回答的原文,我就不多说什么了,呵呵,很有趣的。



 本文转自 dog250 51CTO博客,原文链接:http://blog.51cto.com/dog250/1273952

版权声明:本文内容由阿里云实名注册用户自发贡献,版权归原作者所有,阿里云开发者社区不拥有其著作权,亦不承担相应法律责任。具体规则请查看《阿里云开发者社区用户服务协议》和《阿里云开发者社区知识产权保护指引》。如果您发现本社区中有涉嫌抄袭的内容,填写侵权投诉表单进行举报,一经查实,本社区将立刻删除涉嫌侵权内容。

分享:
开发与运维
使用钉钉扫一扫加入圈子
+ 订阅

集结各类场景实战经验,助你开发运维畅行无忧

其他文章
最新文章
相关文章