imtgj的专栏

抽了个空，吧ubuntu给升级了，下面把升级的过程步骤描述下：  1、下载11.04的iso文件2、解压到d：如D:/ubuntu113、把casper目录中的vmlinuz，initrd.lz拷贝到d盘根目录下4、restart5、grub的启动菜单里，按c进入命令行模式6、执行kernel hd(0,4)/vmlinuz boot=casper iso-sc

按照计划，本想写一篇负载均衡的调度算法分析，但查看了网上的资料，发现这篇文章已经写的比较好，我都没用那么大的耐心写的那么详细。 下面是我在网上找到的资料，这里发个链接。 http://blog.youkuaiyun.com/dog250/article/details/6538240 另外，在这里简单总结一下： 1，负载均衡的调度只是针对非实时任务，原因，参考我前面的文章：实时任务调度算法

一、概述 在计算机系统，CPU是以一个节拍一个节拍运行的（cpu cycle），这就是CPU的频率（HZ)。类似的，操作系统需要提供超时功能，显示时间（如PC机右下角的时钟），统计（CPU占有率计算）等功能，也需要有一个节拍（操作系统的频率HZ）触发操作系统做上述相关功能处理，内核在内部使用了一个全局变量记录了系统从启动后经过了多少个节拍，这就是tick值，通常由另外一个更形象的说法“嘀嗒”，在

前段时间收到一位同事的邮件，就某个问题进行了阐述，读后如鲠在喉，不吐不快。 邮件大意如下：进程复位重启后，等待3秒读取后台文件，发现读取不了，后来修改为6秒，还是不行，最后定位因xx原因导致后台文件没有生成。 我想说的是，假如修改为6秒后，侥幸成功了，是不是就这样认为问题解决了？为什么3秒不行，就能假设6秒是OK的呢？开始读取失败的时候有没有分析问题的根因？ 还有多少类似的问题是这么解决的？

CFS算法是基于一个理想的，精确的多任务CPU设计的（在这种CPU下，各个任务的运行速度是一 致的），实际上这个CPU并不存在，因此，算法模拟了硬件的实现，通过分割CPU的时间使得每个任务的 运行时间总是相等的。实现上，在每个任务控制块的调度实体上有一个变量vruntime保存了本任务的运 行时间，调度时找时间最小的任务运行，使得最后每个任务的运行时间都相等。 当然，不会当运行时间最小的任

一、中断概述 中断的目的就是让CPU能响应某种突发事件并做出处理。 如网卡收到了一个报文，需要通知CPU对该报文进行处理。这种一般称之为外部中断，让CPU与其他硬件设备能够配合工作。 另外一类中断（或者说异常），是由CPU内部触发的，如代码执行过程中发生了除0错误，访问了不存在的地址等，这种一般称之为内 部中断。 由于这两类中断的处理机制与流程基本一致，因此，从中断处理代码来说，通常不加

----一年前写的东西，重新抄录以防遗忘。 glibc提供的pthread互斥信号量可以用在进程内部，也可以用在进程间，可以在初始化时通过pthread_mutexattr_setpshared接口设置该信号 量属性，表示是进程内还是进程间。进程内的使用较为简单，本文的总结主要是针对进程间的，进程内的也可以参考，其代码实现原理是类似 的。 一、实现原理 pthread mut

接口设计上，简单、没有二义性是必须的。但是简单，则可能带来滥用。 为什么这么说呢？先看一个例子。在vxworks里，共享资源的互斥一般可 通过信号量、锁任务（tasklock/taskunlock--禁止/使能任务调度功能） ,锁中断（intlock/intunlock--关闭/使能中断）来实现。这几个接口， 影响的程度不同，一般的编程手册（包括vxworks的帮助文档），都是建 议首先

先来看一个开发实例： 静态内存模块主要功能是根据指定的（模块号，所需内存大小）从某个固定的区域划分内存，在运行过程中不会有申请释放操作。 如有一块5M的内存空间addr，分别有5个模块，每个模块所需的内存为（1MB,2MB,1MB,0.5MB,0.5MB),则各模块分到的地址如下 （addr,addr+1MB, addr+3MB, addr+4MB,addr+4.5MB)。当然还有其他的一些

需求到代码的距离有多远？也许很近，就在转角的街区，也许很远，就像6级专家与1级编码工的距离，取决于你的代码是如何实现的。 先来看一个简单的需求：网口状态down时删除路由表项。 非常简单的一种实现： int link_down() { do_something(); delete_route(); //删除路由 } 需求与代码的距离如此之近，近的来不及反应就

先看一个实例： 有一个公共库（下面称之为D)，提供了很多公共模块，内存管理是其中之一，内存管理包括了内存分区（静态内存区，动态内存区，扩展内存 区），申请释放，泄露检测，破坏检测等功能。某一个组件（下面称之为V）使用了公共库的内存管理，从扩展分区中申请了内存，V组件会有 缓存--会把申请到的内存缓存起来使用。 问题来了，由于D默认会使能泄露检测，导致认为V缓存的内存是泄露了，然后报

如何编好代码，无论函数间，还是模块间，架构设计上，似乎都逃不开这六个字，高内聚低耦合。 抽象，抽象，再抽象，抽象出抽象接口，基于抽象接口编程，这就是低耦合。 KISS,KISS,再KISS，保持代码简洁，功能单一，甚至一眼看过去就知道有没有错，这就是高内聚。非常赞同这一条，代码有两种：一种是简单的看过去就知道没有问题的，另一种是复杂的让人看不出有什么问题的。

有个内存管理模块对应用屏蔽了不同环境的内存差异，提供了统一的内存管理接口及机制。其内部层次大致如下： facade ----------> 抽象实现 ------->具体的内存接口（根据实际运行内存管理配置）。 在三种实际环境中会用到某个库的内存申请释放操作，而这个第三方库的内存操作接口在两种环境下是一样的，在第三种环境下则是不同的，差异在某个接口的参数上。如内存申请的ID号，在前