上周做了一个周年庆的抽奖的需求, 抽奖的规则一般就是在概率的基础上, 将奖品按时间跨度均匀分配, 奖励有实物和虚拟奖励. 抽奖代码的核心在:按时间轴均匀分配奖励和严格控制奖励的数量, 不能出现数量的不一致.

昨天上线后, 今天早上发生了一件从来没有想到会发生的bug, 就是抽奖滚屏公告不见了, 就是前台拉取不到中奖滚屏信息了. 果然是万万没想到呀! 通过脚本直接从后台拉取也是同样的结果, 问题出现在哪里?

walker · [email protected]

在听完leader的<分布式rpc框架的介绍>课程后，对其中协程的实现方式有了基本的了解，无论的POSIX的ucontex，boost::fcontext，还是libco，都是通过保存和恢复寄存器状态，来进行各个协程上下文的保存和切换。所以有了这篇对ucontext实现原理的分析。
文章首先初略的温习了一下汇编的一些基础知识，其次就是ucontext源码分析，最后是一个ucontext示例极其调试过程。

1. Linux内核时钟系统和定时器实现

**Linux 2.6.16之前**，内核只支持低精度时钟，内核定时器的工作方式：

• 系统启动后，会读取时钟源设备(RTC, HPET，PIT…),初始化当前系统时间；
• 内核会根据HZ(系统定时器频率，节拍率)参数值，设置时钟事件设备，启动tick(节拍)中断。HZ表示1秒种产生多少个时钟硬件中断，tick就表示连续两个中断的间隔时间。在我电脑上，HZ=250， 一个tick = 1/HZ, 所以默认一个tick为4ms。

  1 2	cat /boot/config-`uname -r` | grep 'CONFIG_HZ=' CONFIG_HZ=250

• 设置时钟事件设备后，时钟事件设备会定时产生一个tick中断，触发时钟中断处理函数，更新系统时钟,并检测timer wheel，进行超时事件的处理。

写了这么多年代码，地址这个东西每天都会使用，那么今天总结一下地址这个东西的由来。
本文参考了参考了《程序员的自我修养》一书.

本文简单介绍nginx conf文件的结构，已经如何进行配置：

Boost Interprocess组件提供了通过了托管内存段(managed_mapped_file & managed_shared_memory)在共享内存和内存映射文件上进行复杂数据结构构建的功能。

本人github主站：https://anonymalias.github.io
本人csdn主站：http://blog.csdn.net/anonymalias

GitHub本身支持建站:只需在自己的repos下建立一个名为：username.github.io的repo，然后在该repo下发布静态站点文件可以了。
下面是详细的在linux下建站流程：

Boost的提供了一套ipc的接口，内存映射文件将文件的内容映射到进程的地址空间。