博客园_大熊 | Zealot Yin

线程同步之条件变量使用手记

2012-04-18T11:14:00Z

由来：

最近一直在想怎么高效率的在IO线程接收到数据时通知逻辑线程（基于线程池）工作的问题，像网络编程的服务器模型的一些模型都需要用到这个实现，下面我这里简单的罗列一个多线程的网络服务器模型

半同步/半异步（half-sync/half-async）：

许多餐厅使用半同步/半异步模式的变体。例如，餐厅常常雇佣一个领班负责迎接顾客，并在餐厅繁忙时留意给顾客安排桌位，为等待就餐的顾客按序排队是必要的。领班由所有顾客“共享”，不能被任何特定顾客占用太多时间。当顾客在一张桌子入坐后，有一个侍应生专门为这张桌子服务。

对于上面罗列的这种模型，本文讨论的问题是当领班接到客人时，如何高效率的通知侍应生去服务顾客.

在我们使用很广泛的线程池实现中，也会有一样的问题

方法实现：

1.使用锁+轮询

使用这种方法可以很简单的实现，但是会有一定的性能消耗，其还有一个点要好好把握，就是一次轮询没有结果后相隔多久进行下一次的轮询，间隔时间太短，消耗的CPU资源较多，间隔时间太长，不能很及时的响应请求。这就相当于上面的这个例子，侍应生时不时的取询问领班有没有顾客到来

2.使用条件变量的线程同步

线程条件变量pthread_cond_t

线程等待某个条件

int pthread_cond_timedwait(pthread_cond_t *restrict cond,pthread_mutex_t *restrict mutex,const struct timespec *restrict abstime);
int pthread_cond_wait(pthread_cond_t *restrict cond,pthread_mutex_t *restrict mutex);
通知函数

通知所有的线程

int pthread_cond_broadcast(pthread_cond_t *cond);

只通知一个线程
int pthread_cond_signal(pthread_cond_t *cond);

正确的使用方法

pthread_cond_wait用法：

pthread_mutex_lock(&mutex);

while(condition_is_false)

{

pthread_cond_wait(&cond,&mutex);

}

condition_is_false=true; //此操作是带锁的，也就是说只有一个线程同时进入这块

pthread_mutex_unlock(&mutex);

pthread_cond_signal用法：

pthread_mutex_lock(&mutex);

condition_is_false=false;

pthread_cond_signal(&cond)

pthread_mutex_unlock(&mutex)

我刚初用的时候，觉得非常的奇怪，为什么要这样用，加了mutex后还需要一个condition_is_false变量来表示有没有活干。其实这样子的一个操作主要是为了解决“假激活”问题，因为我么您这里的使用场景，只需要激活一个线程，因为一个线程干一个活，而不是多个线程干一个活，所以为了避免线程被激活了，但实际又没有事情干，所以使用了这么一套机制。

实际上，信号和pthread_cond_broadcast是两个常见的导致假唤醒的情况。假如条件变量上有多个线程在等待,pthread_cond_broadcast会唤醒所有的等待线程，而pthread_cond_signal只会唤醒其中一个等待线程。这样,pthread_cond_broadcast的情况也许要在pthread_cond_wait前使用while循环来检查条件变量。

来个例子：

1 #include <pthread.h>
2 #include <stdio.h>
3 #include<stdlib.h>
4 #include<unistd.h>
5
6 /* For safe condition variable usage, must use a boolean predicate and */
7 /* a mutex with the condition. */
8 int workToDo = 0;
9 pthread_cond_t cond = PTHREAD_COND_INITIALIZER;
10 pthread_mutex_t mutex = PTHREAD_MUTEX_INITIALIZER;
11
12 #define NTHREADS 20
13
14 static void checkResults(char *string, int rc) {
15 if (rc) {
16 printf("Error on : %s, rc=%d",
17 string, rc);
18 exit(EXIT_FAILURE);
19 }
20 return;
21 }
22
23 void *threadfunc(void *parm)
24 {
25 int rc;
26
27 while (1) {
28 /* Usually worker threads will loop on these operations */
29 rc = pthread_mutex_lock(&mutex);
30 checkResults("pthread_mutex_lock()\n", rc);
31
32 while (!workToDo) {
33 printf("Thread blocked\n");
34 rc = pthread_cond_wait(&cond, &mutex);
35 checkResults("pthread_cond_wait()\n", rc);
36 }
37 printf("Thread awake, finish work!\n");
38 sleep(2);
39 /* Under protection of the lock, complete or remove the work */
40 /* from whatever worker queue we have. Here it is simply a flag */
41 workToDo = 0;
42 printf("In mutex lock\n");
43 rc = pthread_mutex_unlock(&mutex);
44 sleep(2);
45 printf("Out mutex lock\n");
46 checkResults("pthread_mutex_lock()\n", rc);
47 }
48 return NULL;
49 }
50
51 int main(int argc, char **argv)
52 {
53 int rc=0;
54 int i;
55 pthread_t threadid[NTHREADS];
56
57 printf("Enter Testcase - %s\n", argv[0]);
58
59 printf("Create %d threads\n", NTHREADS);
60 for(i=0; i<NTHREADS; ++i) {
61 rc = pthread_create(&threadid[i], NULL, threadfunc, NULL);
62 checkResults("pthread_create()\n", rc);
63 }
64
65 sleep(5); /* Sleep is not a very robust way to serialize threads */
66
67 for(i=0; i<5; ++i) {
68 printf("Wake up a worker, work to do...\n");
69
70 rc = pthread_mutex_lock(&mutex);
71 checkResults("pthread_mutex_lock()\n", rc);
72
73 /* In the real world, all the threads might be busy, and */
74 /* we would add work to a queue instead of simply using a flag */
75 /* In that case the boolean predicate might be some boolean */
76 /* statement like: if (the-queue-contains-work) */
77 if (workToDo) {
78 printf("Work already present, likely threads are busy\n");
79 }
80 workToDo = 1;
81 rc = pthread_cond_broadcast(&cond);
82 // rc = pthread_cond_signal(&cond);
83 checkResults("pthread_cond_broadcast()\n", rc);
84
85 rc = pthread_mutex_unlock(&mutex);
86 checkResults("pthread_mutex_unlock()\n", rc);
87 sleep(5); /* Sleep is not a very robust way to serialize threads */
88 }
89
90 printf("Main completed\n");
91 exit(0);
92 return 0;
93 }

事实上上面的例子无论是使用pthread_cond_signal还是pthread_cond_broadcast，都只会打印Thread awake, finish work5次，大家可能会觉得非常奇怪，但是实际情况就是这样的。为了明白其pthread_cont_wait内部干了什么工作，有必要深入一下其内部实现。

关于其内部实现伪代码如下：

1 pthread_cond_wait(mutex, cond):
2 value = cond->value; /* 1 */
3 pthread_mutex_unlock(mutex); /* 2 */
4 pthread_mutex_lock(cond->mutex); /* 10 */ pthread_cond_t自带一个mutex来互斥对waiter等待链表的操作
5 if (value == cond->value) { /* 11 */ 检查一次是不是cond有被其他线程设置过，相当于单例模式的第二次检测是否为NULL
6 me->next_cond = cond->waiter;
7 cond->waiter = me;//链表操作
8 pthread_mutex_unlock(cond->mutex);
9 unable_to_run(me);
10 } else
11 pthread_mutex_unlock(cond->mutex); /* 12 */
12 pthread_mutex_lock(mutex); /* 13 */
13
14 pthread_cond_signal(cond):
15 pthread_mutex_lock(cond->mutex); /* 3 */
16 cond->value++; /* 4 */
17 if (cond->waiter) { /* 5 */
18 sleeper = cond->waiter; /* 6 */
19 cond->waiter = sleeper->next_cond; /* 7 */ //链表操作
20 able_to_run(sleeper); /* 8 */ 运行sleep的线程，即上面的me
21 }
22 pthread_mutex_unlock(cond->mutex); /* 9 */

pthread_cond_broadcast虽然能够激活所有的线程，但是激活之后会有mutex锁，也就是说他的激活是顺序进行的，只有第一个激活的线程调用pthread_mutex_unlock(&mutex)后，后一个等待的线程才会继续运行.因为从pthread_cond_wait(&cond,&mutex)到pthread_mutex_unlock(&mutex)区间是加的独占锁，从wait激活后的第一个线程占用了这个锁，所以其他的线程不能运行，只能等待。所以当第一个被激活的线程修改了condition_is_false后（上面测试代码的workToDo），接着调用pthread_mutex_unlock(&mutex)后，此时其他等待在cond的一个线程会激活，但是此时condition_is_false已经被设置，所以他跑不出while循环，当调用pthread_cond_wait时，其内部pthread_mutex_unlock(mutex)调用会导致另一个在它后面的等待在cond的线程被激活。

所以，通过这种方式，即便是误调用了pthread_cond_broadcast或者由于信号中断的原因激活了所有在等待条件的线程，也能保证其结果是正确的。

另外说一句题外话，很多人写的基于条件变量线程同步的框架，说自己是无锁的，其实这是不对的，只是内部锁的机制在pthread_cond_wait实现了而已，其还是基于互斥锁的实现。真正想要达到无锁的可以关注一下lockfree相关的CAS算法，其内部使用一个intel CPU的cmpxchg8指令完成的，其实这种实现个人认为和传统锁相比只是一个非阻塞锁和阻塞锁的区别。

本文链接

内存池技术畅想

2012-04-10T17:04:00Z

内容：

本文将介绍几种常用的内存池技术的实现，这是我最近学习各大开源的内存池技术遗留下来的笔记，其主要内容包括：

STL内存池以及类STL内存池实现
Memcached内存池实现
固定规格内存池实现
Nginx内存池实现

一.类STL的内存池实现方式

SGI STL的内存池分为一级配置器和二级配置器，

一级配置器主要处理分配空间大小大于128Byte的需求，其内部实现就是直接使用malloc realloc 和free.

二级配置器则使用使用free_list的数组链表的方式来管理内存，SGI的Allocate最小的分辨单位为8Byte,其free_list数组存着8*n（n=1...16)大小内存的首地址,大小同样的内存块使用链表的形式相连

free_list[0] --------> 8 byte

free_list[1] --------> 16 byte

free_list[2] --------> 24 byte

free_list[3] --------> 32 byte
... ...
free_list[15] -------> 128 byte

因为其对内存的管理的最小分辨度为8Byte,所以当我们申请的内存空间不是8的倍数的时候，内存池会将其调整为8的倍数大小，这叫内存对齐。当然这也免不了带来内存浪费，例如我们只需要一个10Byte的大小，内存池经过内存对齐后，会给我们一个16Byte的大小，而剩余的6Byte，在这次使用中根本没有用到。（对于chunk_allocate的优化请见探究操作系统的内存分配（malloc）对齐策略一文的末尾处）

类STL的内存池一般都有如下API

void* allocate(size_t __n) //外部API，分配内存

void deallocate(void* __p, size_t __n)//外部API，回收内存，以供再利用

char* chunk_alloc(size_t __size, int& __nobjs)//内部函数，用于分配一个大块

void* refill(size_t n) //内部函数，用于allocate从free_list中未找到可使用的块时调用

这种内存池的工作流程大致如下：

外部调用 allocate向内存池申请内存
allocate通过内存对齐的方式在free_list找到合适的内存块链表头
判断链表头是否为NULL,为NULL则表示没有此规格空闲的内存，如果不为NULL，则返那块内存地址，并将此块内存地址移除它对应的链表
如果为NULL，则调用refill在freelist上挂载20个此规格的内存空间（形成链表），也就是保证此规格的内存空间下次请求时够用
refill的内部调用了chunk_alloc函数，chunk_alloc的职责就是负责内存池的所有内存的生产，在生产的时候他为了保证下次能有内存用，所以会将空间*2，所以这个申请流程总的内存消耗为：（对需求规格内存对齐后的大小）*20*2

下面举一个例子来简单得说明一下：

当第一次调用chunk_alloc(32,10)的时候，表示我要申请10块__Obje(free_list)，每块大小32B，此时，内存池大小为0，从堆空间申请32*20的大小的内存，把其中32*10大小的分给free_list[3]。
我再次申请64*5大小的空间，此时free_list[7]为0，它要从内存池提取内存，而此时内存池剩下320B，刚好填充给free_list[7]，内存池此时大小为0。
第三次请求72*10大小的空间，此时free_list[8]为0，它要从内存池提取内存，此时内存池空间不足，再次从堆空间申请72*20大小的空间，分72*10给free_list用。

首次申请20Byte后的状态图：

在未设置预分配的STL内存池中，某个中间状态的整体图

由于STL源码可阅读性不强，各种宏等等满目不堪，所以我这里就不贴SGI 的源码了，我在这里贴一个简单易懂的山寨版本，基本的思路是一模一样的，这个实现没有了一级和二级配置器，而是在需要的时候直接malloc或者从free_list找。

  1 .
  2 #ifndef MEMORYPOOL_H
  3 #define MEMORYPOOL_H
  4
  5 #include <stdio.h>
  6 #include <assert.h>
  7
  8 using namespace std;
  9
10 class MemoryPool
11 {
12 private:
13
14     // Really we should use static const int x = N
15     // instead of enum { x = N }, but few compilers accept the former.
16     enum {__ALIGN = 8};                            //小型区块的上调边界，即小型内存块每次上调8byte
17     enum {__MAX_BYTES = 128};                    //小型区块的上界
18     enum {__NFREELISTS = __MAX_BYTES/__ALIGN};    //free-lists的个数，为:16，每个free-list管理不同大小内存块的配置
19
20   //将请求的内存大小上调整为8byte的倍数，比如8byte, 16byte, 24byte, 32byte
21   static size_t ROUND_UP(size_t bytes)
22   {
23         return (((bytes) + __ALIGN-1) & ~(__ALIGN - 1));
24   }
25
26   union obj
27   {
28       union obj* free_list_link;        //下一个区块的内存地址，如果为NULL，则表示无可用区块
29       char client_data[1];                //内存区块的起始地址
30   };
31
32 private:
33     static obj *free_list[__NFREELISTS];    // __NFREELISTS = 16
34     /*
35         free_list[0] --------> 8 byte（free_list[0]管理8bye区块的配置）
36         free_list[1] --------> 16 byte
37         free_list[2] --------> 24 byte
38         free_list[3] --------> 32 byte
39         ... ...
40         free_list[15] -------> 128 byte
41     */
42
43   //根据区块大小，决定使用第n号的free_list。n = [0, 15]开始
44   static  size_t FREELIST_INDEX(size_t bytes)
45   {
46         return (((bytes) + __ALIGN-1)/__ALIGN - 1);
47   }
48
49   // Returns an object of size n, and optionally adds to size n free list.
50   static void *refill(size_t n);
51
52   // 配置一大块空间，可容纳nobjs个大小为size的区块
53   // 如果配置nobjs个区块有所不便，nobjs可能会降低
54   static char *chunk_alloc(size_t size, int &nobjs);
55
56   // Chunk allocation state.
57   static char *start_free;        //内存池起始位置
58   static char *end_free;        //内存池结束位置
59   static size_t heap_size;        //内存池的大小
60
61 public:
62
63   // 公开接口，内存分配函数
64     static void* allocate(size_t n)
65     {
66         obj** my_free_list = NULL;
67         obj* result = NULL;
68
69         //如果待分配的内存字节数大于128byte,就调用C标准库函数malloc
70         if (n > (size_t) __MAX_BYTES)
71         {
72             return malloc(n);
73         }
74
75         //调整my_free_lisyt，从这里取用户请求的区块
76         my_free_list = free_list + FREELIST_INDEX(n);
77
78
79         result = *my_free_list;        //欲返回给客户端的区块
80
81         if (result == 0)    //没有区块了
82         {
83             void *r = refill(ROUND_UP(n));
84
85             return r;
86         }
87
88         *my_free_list = result->free_list_link;        //调整链表指针，使其指向下一个有效区块
89
90         return result;
91     };
92
93
94     //归还区块
95     static void deallocate(void *p, size_t n)
96     {
97         assert(p != NULL);
98
99         obj* q = (obj *)p;
100         obj** my_free_list = NULL;
101
102         //大于128byte就调用第一级内存配置器
103         if (n > (size_t) __MAX_BYTES)
104         {
105             free(p) ;
106         }
107
108         // 寻找对应的free_list
109         my_free_list = free_list + FREELIST_INDEX(n);
110
111         // 调整free_lis，回收内存
112         q -> free_list_link = *my_free_list;
113         *my_free_list = q;
114   }
115
116   static void * reallocate(void *p, size_t old_sz, size_t new_sz);
117
118 } ;
119
120
121 /* We allocate memory in large chunks in order to avoid fragmenting     */
122 /* the malloc heap too much.                                            */
123 /* We assume that size is properly aligned.                             */
124 /* We hold the allocation lock.                                         */
125
126 // 假设size已经上调至8的倍数
127 // 注意nobjs是passed by reference,是输入输出参数
128 char* MemoryPool::chunk_alloc(size_t size, int& nobjs)
129 {
130     char* result = NULL;
131
132     size_t total_bytes = size * nobjs;                //请求分配内存块的总大小
133     size_t bytes_left = end_free - start_free;        //内存池剩余空间的大小
134
135     if (bytes_left >= total_bytes)     //内存池剩余空间满足要求量
136     {
137         result = start_free;
138         start_free += total_bytes;
139
140         return result;
141     }
142     else if (bytes_left >= size)         //内存池剩余空间不能完全满足需求量，但足够供应一个(含)以上的区块
143     {
144         nobjs = bytes_left/size;        //计算内存池剩余空间足够配置的区块数目
145         total_bytes = size * nobjs;
146
147         result = start_free;
148         start_free += total_bytes;
149
150         return result;
151     }
152     else         //内存池剩余空间连一个区块都无法提供
153     {
154         //bytes_to_get为内存池向malloc请求的内存总量
155         size_t bytes_to_get = 2 * total_bytes + ROUND_UP(heap_size >> 4);
156
157         // Try to make use of the left-over piece.
158         if (bytes_left > 0)
159         {
160             obj** my_free_list = free_list + FREELIST_INDEX(bytes_left);
161
162             ((obj *)start_free) -> free_list_link = *my_free_list;
163             *my_free_list = (obj *)start_free;
164         }
165
166         // 调用malloc分配堆空间，用于补充内存池
167         start_free = (char *)malloc(bytes_to_get);
168         if (0 == start_free)     //heap空间已满，malloc分配失败
169         {
170             int i;
171             obj ** my_free_list, *p;
172
173             //遍历free_list数组，试图通过释放区块达到内存配置需求
174             for (i = size; i <= __MAX_BYTES; i += __ALIGN)
175             {
176                 my_free_list = free_list + FREELIST_INDEX(i);
177                 p = *my_free_list;
178
179                 if (0 != p)
180                 {
181                     *my_free_list = p -> free_list_link;
182                     start_free = (char *)p;
183                     end_free = start_free + i;
184
185                     return chunk_alloc(size, nobjs);
186                     // Any leftover piece will eventually make it to the
187                     // right free list.
188                 }
189             }
190
191             end_free = 0;    // In case of exception.
192
193             // 调用第一级内存配置器，看看out-of-memory机制能否尽点力
194
195             // This should either throw an
196             // exception or remedy the situation.  Thus we assume it
197             // succeeded.
198         }
199
200         heap_size += bytes_to_get;
201         end_free = start_free + bytes_to_get;
202
203         return chunk_alloc(size, nobjs);
204     }
205
206 }
207
208
209 /* Returns an object of size n, and optionally adds to size n free list.*/
210 /* We assume that n is properly aligned.                                */
211 /* We hold the allocation lock.                                         */
212 void* MemoryPool::refill(size_t n)
213 {
214     int nobjs = 20;
215
216     // 注意nobjs是输入输出参数，passed by reference。
217     char* chunk = chunk_alloc(n, nobjs);
218
219     obj* * my_free_list = NULL;
220     obj* result = NULL;
221     obj* current_obj = NULL;
222     obj* next_obj = NULL;
223     int i;
224
225     // 如果chunk_alloc只获得了一个区块，这个区块就直接返回给调用者，free_list无新结点
226     if (1 == nobjs)
227     {
228         return chunk;
229     }
230
231     // 调整free_list，纳入新结点
232     my_free_list = free_list + FREELIST_INDEX(n);
233
234     result = (obj*)chunk;    //这一块返回给调用者(客户端)
235
236
237     //用chunk_alloc分配而来的大量区块配置对应大小之free_list
238     *my_free_list = next_obj = (obj *)(chunk + n);
239
240     for (i = 1; ; i++)
241     {
242         current_obj = next_obj;
243         next_obj = (obj *)((char *)next_obj + n);
244
245         if (nobjs - 1 == i)
246         {
247             current_obj -> free_list_link = NULL;
248             break;
249         }
250         else
251         {
252             current_obj -> free_list_link = next_obj;
253         }
254     }
255
256     return result;
257 }
258
259 //重新配置内存，p指向原有的区块，old_sz为原有区块的大小，new_sz为新区块的大小
260 void* MemoryPool::reallocate(void *p, size_t old_sz, size_t new_sz)
261 {
262     void* result = NULL;
263     size_t copy_sz = 0;
264
265     if (old_sz > (size_t) __MAX_BYTES && new_sz > (size_t) __MAX_BYTES)
266     {
267         return realloc(p, new_sz);
268     }
269
270     if (ROUND_UP(old_sz) == ROUND_UP(new_sz))
271     {
272         return p;
273     }
274
275     result = allocate(new_sz);
276     copy_sz = new_sz > old_sz? old_sz : new_sz;
277
278     memcpy(result, p, copy_sz);
279
280     deallocate(p, old_sz);
281
282     return result;
283 }
284
285 //静态成员变量初始化
286 char* MemoryPool::start_free = 0;
287
288 char* MemoryPool::end_free = 0;
289
290 size_t MemoryPool::heap_size = 0;
291
292 MemoryPool::obj* MemoryPool::free_list[MemoryPool::__NFREELISTS]
293                         = {0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, };
294
295 #endif
296

二.MemCached内存池实现

与类STL内存池不同的是，用于缓存的内存池不是解决小对象的内存分配可能导致堆内存碎片多的问题，缓存内存池要为缓存系统的所有存储对象分配空间，无论大小。因为缓存系统通常对其占用的最大内存有限制，所以也就不能在没有空间用的时候随便malloc来实现了。 MemCached的内存池的基本想法是避免重复大量的初始化和清理操作。

Memcached 中内存分配机制主要理念

1. 先为分配相应的大块内存，再在上面进行无缝小对象填充

2. 懒惰检测机制，Memcached 不花过多的时间在检测各个item对象是否超时，当 get获取数据时，才检查item对象是否应该删除，你不访问，我就不处理。

3. 懒惰删除机制，在 memecached 中删除一个 item对象的时候，并不是从内存中释放，而是单单的进行标记处理，再将其指针放入 slot回收插糟，下次分配的时候直接使用。

MemCached内存池Slab Allocation的主要术语

Page

分配给Slab的内存空间，默认是1MB。分配给Slab之后根据slab的大小切分成chunk。

Chunk

用于缓存记录的内存空间。

Slab Class

特定大小的chunk的组。

Memcached的内存分配以page为单位，默认情况下一个page是1M ，可以通过-I参数在启动时指定。如果需要申请内存时，memcached会划分出一个新的page并分配给需要的slab区域。Memcached并不是将所有大小的数据都放在一起的，而是预先将数据空间划分为一系列slabs，每个slab只负责一定范围内的数据存储，其大小可以通过启动参数设置增长因子，默认为1.25，即下一个slab的大小是上一个的1.25倍。如下图，每个slab只存储大于其上一个slab的size并小于或者等于自己最大size的数据。如下图所示，需要存储一个100Bytes的对象时，会选用112Bytes的Slab Classes

基于这种实现的内存池也会遇到STL内存池一样的问题，那就是资源的浪费，我只需要100Byte的空间，你却给了我128Bytes,剩余的28Bytes就浪费了

其主要API：

slabs_init()

slab初始化，如果配置时采用预分配机制(prealloc)则在先在这使用malloc分配所有内存。

再根据增长因子factor 给每个 slabclass 分配容量。

slabs_clsid()

计算出哪个 slabclass 适合用来储存大小给定为 size的item，如果返回值为 0则存储的物件过大，无法进行存储。

do_slabs_alloc()

在这个函数里面，由宏定义来决定采用系统自带的 malloc 机制还是 memcached的slab机制对内存进行分配，理所当然，在大多数情况下，系统的malloc会比slab慢上一个数量级。分配时首先考虑slot 内的空间(被回收的空间),再检查 end_page_ptr 指针指向的的空闲空间，还是没有的空间的话，再试试分配新的内存。如果所有空间都用尽的时候，则返回NULL表示目前资源已经枯竭了。

do_slabs_free()

首先检查当目前的插糟是否已经达到可用总插糟的总容量，如果达到就为其重新分配空间，再将该回收的 item的指针插入对应当前 id的 slabclass 的插糟（slots）之中。

关于MemCached还有个问题需要解释下，在预分配的场景下，有的同事认为MemCached不适合大量存储某个特定大小范围内的对象，他们认为预分配的条件下，每个SlabClasses的总大小是固定的（为一个Page),其实不是，MemCached预分配并不会消耗掉所有的内存，在请求空间的时候，如果发现这个型号的Chunks都被用完了，就会新增一个分页到这个Slab Classes，所以是不会出现那位同事说的那个问题的...（可见代码slabs.c中do_slabs_alloc函数中do_slabs_newslab的调用）

三.固定大小内存池

上面两种内存池的实现，都会造成一定程度的内存浪费，如果我存的对象大小基本是固定的，尽管有很多不同的对象，有没有不会浪费内存的的简单方式呢？

既然需要存的对象大小是固定的，那么我们的内存池对于内存的管理可以这样实现：

class IovecContainer

{

public:

list<char*> m_objList;

};

class MemoryPool

{

public:

void* allocate(size_t __n) //外部API，分配内存

void deallocate(void* __p, size_t __n)//外部API，回收内存，以供再利用

private:

map<int, IovecContainer* > m_mapPool;

char* chunk_alloc(size_t __size, int& __nobjs)//内部函数，用于分配一个大块
void* refill(size_t n) //内部函数，用于allocate从free_list中未找到可使用的块时调用

};

这样的实现对于这个特定的需求非常好用,不回浪费掉剩余空间，但是这样的实现局限性就高了，我们不能用这个内存池来存储大小不定的对象（如string)，如果用了，此内存池形同虚设，并且还浪费内存，所以具体怎么选择还是要看需求来定...

四.Nginx内存池实现

关于Nginx内存池实现网上有比较多的分析文章，这里我就不重复造轮子了，直接贴链接，有兴趣的可以关注下：

http://blog.csdn.net/v_july_v/article/details/7040425
http://bbs.chinaunix.net/thread-3626006-1-1.html；
http://blog.csdn.net/livelylittlefish/article/details/6586946；
http://blog.chinaunix.net/space.php?uid=7201775；
淘宝数据共享平台博客：http://www.tbdata.org/archives/1390

晚了，睡觉！！！呵呵呵...

参考资料：http://www.cnblogs.com/sld666666/archive/2010/07/01/1769448.html

本文链接

探究操作系统的内存分配（malloc）对齐策略

2012-04-05T09:51:00Z

问题：

我们在写程序的时候经常发现程序使用的内存往往比我们申请的多，为了优化程序的内存占用，搅尽脑汁想要优化内存占用，可是发现自己的代码也无从优化了，怎么办？现在我们把我们的焦点放到malloc上，毕竟我们向系统申请的内存都是通过它完成了，不了解他，也就不能彻底的优化内存占用。

来个小例子

//g++ -o malloc_addr_vec mallc_addr_vec.cpp 编译
2 #include<iostream>
3 using namespace std;
4 int main(int argc, char *argv[])
5 {
6     int malloc_size = atoi(argv[1]);
7     char * malloc_char;
8     for (size_t i = 0; i < 1024*1024; ++i) {
9         malloc_char = new char[malloc_size];
10     }
11     while (1) {}//此时查看内存占用
12     return 0;
13 }

本文的测试环境为Linux 64Bit ,使用G++编译为可执行文件后，使用不同的启动参数启动，使用top命令查看程序占用的内存，这里我们主要是看RES指标

RES -- Resident size (kb)

The non-swapped physical memory a task has used.

测试案例：
1.每次new 1 Byte Do 1024*1024次
./malloc_addr_vec 1
启动程序后的内存占用

内存消耗 32MB
2.每次new 24 Byte Do 1024*1024次
./malloc_addr_vec 24
启动程序后的内存占用

内存消耗32MB
3.每次new 25 Byte Do 1024*1024次
./malloc_addr_vec 25
启动程序后的内存占用

内存消耗48MB

为什么我们每次new 1Byte 和每次 new 24Byte系统消耗的内存一样呢？，为什么每次new 25Byte和每次new 24Byte占用的内存完全不同呢？

不知道大家在写程序的时候有没有关注过这个问题。我一次遇到时，吐槽一句：What the fuck malloc.

原因分析：

在大多数情况下，编译器和C库透明地帮你处理对齐问题。POSIX 标明了通过malloc( ), calloc( ), 和 realloc( ) 返回的地址对于任何的C类型来说都是对齐的。

对齐参数（MALLOC_ALIGNMENT）大小的设定并需满足两个特性

1.必须是2的幂
2.必须是(void *)的整数倍

至于为什么会要求是(void *)的整数倍，这个目前我还不太清楚，等你来发现...

根据这个原理，在32位和64位的对齐单位分别为8字节和16字节

但是这并解释不了上面的测试结果，这是因为系统malloc分配的最小单位（MINSIZE）并不是对齐单位

为了进一步了解细节，从GNU网站中把glibc源码下载下来，查看其 malloc.c文件

View Code

1 #ifndef INTERNAL_SIZE_T
2 #define INTERNAL_SIZE_T size_t
3 #endif
4 #define SIZE_SZ                (sizeof(INTERNAL_SIZE_T))
5 #ifndef MALLOC_ALIGNMENT
6 #define MALLOC_ALIGNMENT       (2 * SIZE_SZ)
7 #endif
8
9
10 struct malloc_chunk {
11   INTERNAL_SIZE_T      prev_size;  /* Size of previous chunk (if free).  */
12   INTERNAL_SIZE_T      size;       /* Size in bytes, including overhead. */
13   struct malloc_chunk* fd;         /* double links -- used only if free. */
14   struct malloc_chunk* bk;
15 };
16
17     An allocated chunk looks like this:
18     chunk-> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
19             |             Size of previous chunk, if allocated            | |
20             +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
21             |             Size of chunk, in bytes                       |M|P|
22       mem-> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
23             |             User data starts here...                          .
24             .                                                               .
25             .             (malloc_usable_size() bytes)                      .
26             .                                                               |
27 nextchunk-> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
28             |             Size of chunk                                     |
29             +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
30
31
32 #define MALLOC_ALIGN_MASK      (MALLOC_ALIGNMENT - 1)
33 #define MIN_CHUNK_SIZE        (sizeof(struct malloc_chunk))
34 #define MINSIZE  /
35   (unsigned long)(((MIN_CHUNK_SIZE+MALLOC_ALIGN_MASK) & ~MALLOC_ALIGN_MASK))
36 /* pad request bytes into a usable size -- internal version */
37 #define request2size(req)                                         /
38   (((req) + SIZE_SZ + MALLOC_ALIGN_MASK < MINSIZE)  ?             /
39    MINSIZE :                                                      /
40    ((req) + SIZE_SZ + MALLOC_ALIGN_MASK) & ~MALLOC_ALIGN_MASK)

其中request2size这个宏就是glibc的内存对齐操作，MINSIZE就是使用malloc时占用内存的最小单位。根据宏定义可推算在32位系统中MINSIZE为16字节，在64位系统中MINSIZE一般为32字节。从request2size还可以知道，如果是64位系统，申请内存为1~24字节时，系统内存消耗32字节，当申请内存为25字节时，系统内存消耗48字节。如果是32位系统，申请内存为1~12字节时，系统内存消耗16字节，当申请内存为13字节时，系统内存消耗24字节。

一般他们的差距是一个指针大小，计算公式是

max(MINSIZE,in_use_size)
其中in_use_size=(要求大小+2*指针大小-指针大小)align to MALLOC_ALIGNMENT
(对于上面计算的由来可以参见glibc 内存池管理 ptmalloc这篇文章的第4节chuck部分以及搜一下malloc的内部实现源码）

为了证明这个理论的正确性，我们需要计算一次malloc到底花掉了多少内存，我们用如下代码分别在32bit Linux和 64bit Linux上做测试

2 #include<stdio.h>
3 #include<stdlib.h>
4 int main()
5 {
6         char * p1;
7         char * p2;
8         int i=1;
9         printf("%d\n",sizeof(char *));
10         for(;i<100;i++)
11         {
12                 p1=NULL;
13                 p2=NULL;
14                 p1=(char *)malloc(i*sizeof(char));
15                 p2=(char *)malloc(1*sizeof(char));
16                 printf("i=%d     %d\n",i,(p2-p1));
17         }
18
19         getchar();
20 }

其测试结果如下：

32bit

View Code

  1 ---------------------
  2 Linux  32bit
  3 ---------------------
  4 4
  5 i=1 16
  6 i=2 16
  7 i=3 16
  8 i=4 16
  9 i=5 16
10 i=6 16
11 i=7 16
12 i=8 16
13 i=9 16
14 i=10 16
15 i=11 16
16 i=12 16
17 i=13 24
18 i=14 24
19 i=15 24
20 i=16 24
21 i=17 24
22 i=18 24
23 i=19 24
24 i=20 24
25 i=21 32
26 i=22 32
27 i=23 32
28 i=24 32
29 i=25 32
30 i=26 32
31 i=27 32
32 i=28 32
33 i=29 40
34 i=30 40
35 i=31 40
36 i=32 40
37 i=33 40
38 i=34 40
39 i=35 40
40 i=36 40
41 i=37 48
42 i=38 48
43 i=39 48
44 i=40 48
45 i=41 48
46 i=42 48
47 i=43 48
48 i=44 48
49 i=45 56
50 i=46 56
51 i=47 56
52 i=48 56
53 i=49 56
54 i=50 56
55 i=51 56
56 i=52 56
57 i=53 64
58 i=54 64
59 i=55 64
60 i=56 64
61 i=57 64
62 i=58 64
63 i=59 64
64 i=60 64
65 i=61 72
66 i=62 72
67 i=63 72
68 i=64 72
69 i=65 72
70 i=66 72
71 i=67 72
72 i=68 72
73 i=69 80
74 i=70 80
75 i=71 80
76 i=72 80
77 i=73 80
78 i=74 80
79 i=75 80
80 i=76 80
81 i=77 88
82 i=78 88
83 i=79 88
84 i=80 88
85 i=81 88
86 i=82 88
87 i=83 88
88 i=84 88
89 i=85 96
90 i=86 96
91 i=87 96
92 i=88 96
93 i=89 96
94 i=90 96
95 i=91 96
96 i=92 96
97 i=93 104
98 i=94 104
99 i=95 104
100 i=96 104
101 i=97 104
102 i=98 104
103 i=99 104

64bit

View Code

  1 -------------------
  2 Linux  64bit
  3 -------------------
  4 8
  5 i=1 32
  6 i=2 32
  7 i=3 32
  8 i=4 32
  9 i=5 32
10 i=6 32
11 i=7 32
12 i=8 32
13 i=9 32
14 i=10 32
15 i=11 32
16 i=12 32
17 i=13 32
18 i=14 32
19 i=15 32
20 i=16 32
21 i=17 32
22 i=18 32
23 i=19 32
24 i=20 32
25 i=21 32
26 i=22 32
27 i=23 32
28 i=24 32
29 i=25 48
30 i=26 48
31 i=27 48
32 i=28 48
33 i=29 48
34 i=30 48
35 i=31 48
36 i=32 48
37 i=33 48
38 i=34 48
39 i=35 48
40 i=36 48
41 i=37 48
42 i=38 48
43 i=39 48
44 i=40 48
45 i=41 64
46 i=42 64
47 i=43 64
48 i=44 64
49 i=45 64
50 i=46 64
51 i=47 64
52 i=48 64
53 i=49 64
54 i=50 64
55 i=51 64
56 i=52 64
57 i=53 64
58 i=54 64
59 i=55 64
60 i=56 64
61 i=57 80
62 i=58 80
63 i=59 80
64 i=60 80
65 i=61 80
66 i=62 80
67 i=63 80
68 i=64 80
69 i=65 80
70 i=66 80
71 i=67 80
72 i=68 80
73 i=69 80
74 i=70 80
75 i=71 80
76 i=72 80
77 i=73 96
78 i=74 96
79 i=75 96
80 i=76 96
81 i=77 96
82 i=78 96
83 i=79 96
84 i=80 96
85 i=81 96
86 i=82 96
87 i=83 96
88 i=84 96
89 i=85 96
90 i=86 96
91 i=87 96
92 i=88 96
93 i=89 112
94 i=90 112
95 i=91 112
96 i=92 112
97 i=93 112
98 i=94 112
99 i=95 112
100 i=96 112
101 i=97 112
102 i=98 112
103 i=99 112

了解了malloc的内存对其原理后，对于程序的内存占用的优化又有了有的放矢。我们可以根据内存对齐的原则来请求内存，来制作我们的高效内存池，从而避免隐形的资源浪费.

例如，目前STL的内存池是以8Byte为对齐单位，内存池free_list大小为

free_list[0] --------> 8 byte

free_list[1] --------> 16 byte

free_list[2] --------> 24 byte

free_list[3] --------> 32 byte
... ...

free_list[15] -------> 128 byte

STL内存池在发现某个规则的内存用完了时，会进行refill,在进行chunk_alloc

例如8Byte大小的空间没有了，调用refill,refill会将其空间准备20个,也就是20*8，当然refill做不了内存分配，他把20个8Byte的需求提交给chunk_alloc

chunk_alloc 能真正分配内存，但是它分配的时候会将内存空间*2，所以最终malloc的内存为8*20*2=320 ，32bit系统给malloc的内存为328,64bit系统给malloc的内存为336

在32位和64位操作系统分别浪费掉8Byte和16Byte,其实我们可以在chunk_alloc内部简单的计算一下系统的内存对齐，达到 chunk_alloc 级零浪费...

至于 allocate级别的浪费，我想是避免不了了，譬如，我需要一个6Byte的空间，STL内存池给我的确实8Byte

参考资料：http://blog.csdn.net/elpmis/article/details/4500917

本文链接

如何实现文件增量同步——算法

2012-03-30T14:22:00Z

问题：

如何增量同步文件，例如一个文本文件有10M，分别存放在A，B两个地方，现在两个文件是完全一样的，但是我马上要在A上对这个文件进行修改，B如何实现自动和A上的文件保持一致，并且网络的传输量最少。

应用场景：

这样的使用场景太多，这里随便列举几个

1.A机器为线上运营的机器，现在需要一台备份的机器B，当A发生宕机的时候，或者硬盘损坏等各种认为非人为原因导致数据不可用时，可以很快从B恢复

2.SVN这样的应用场景，不需要每次修改都向服务器发送并替换掉一个文件，而是只发送被修改的部分

3.手机客户端对一个文本修改，如果那个文本有2M，难道我每次更新都需要上传整个文件吗？每次2M，傻子才用!

等等....

解决方案：

一.分而治之

计算机最重要的基本算法思路就是分而治之，在我们眼里，一个文件不是一个文件，而是一堆存储块，每个存储块可能20Byte大小，至于这个值具体多大，你可以自己设定,这里的20Byte仅提供参考。通过这样的方法，一个文件被分成了很多个块，我们只需要比对块是否相同就可以得出哪个部分做了相应修改。

二.快速校验

刚上面提到如何比对文件，当然这里肯定不会把文件的每个块上传去比对，那样做就没有意义了。快速比对这不禁让我想起了哈希规则，哈希表可以通过O（1）的复杂度查找某个key，为什么？因为它通过计算hash值来初步验证key，一个key的hash值是唯一的。但是仅仅验证hash值是不可靠的，因为hash值有可能会冲突，所以在验证完hash值后，我们在进行key的比较来确定要找的值...

通过哈希的思路，我们可以使用类似的方法来实现文件增量同步，把每一个存储块，通过MD5计算其值，然后传递MD5值到服务器，让服务器比对MD5来确定有没有被修改，如若MD5值不相等，则判定这个文件块有被修改过

为什么是MD5？

1）能够将任意长度的字符串转换为128位定长字符串（MD5 16)

2）MD5能够保证绝大部分情况下不同的值hash之后其hash值不一样，哈希冲突比较少

这样就可以了吗？

No,MD5的生成需要占用比较长的CPU时间，所以我们需要寻找一种更简洁的校验方式，这里选用Alder32 是一个比较通用的解决方案

Alder32有两个优点：

1、计算非常快，比MD5快多了，成本小；

2、当我们有了从0-k长度的校验和后，计算出1-k或者2-k等其他校验和非常方便，只要少量运算即可。(k可以理解为上面的20Byte)

当然，它的缺点也很明显，就是碰撞率比MD5高多了，所以，我们客户端需要同时计算出Alder32校验和与MD5值，传给服务器，而服务器，为了节省CPU时间，第一步只生成Alder32进行校验，当值相等时，在进行MD5校验，这样服务器就节省了很大的开支。

Alder32算法实现：

A = 1 + D1 + D2 + ... + Dn (mod 65521)
B = (1 + D1) + (1 + D1 + D2) + ... + (1 + D1 + D2 + ... + Dn) (mod 65521)
= n×D1 + (n−1)×D2 + (n−2)×D3 + ... + Dn + n (mod 65521)

Adler-32(D) = B × 65536 + A

C实现版本

const int MOD_ADLER = 65521;

unsigned long adler32(unsigned char *data, int len) /* where data is the location of the data in physical memory and
                                                       len is the length of the data in bytes */
{
    unsigned long a = 1, b = 0;
    int index;

    /* Process each byte of the data in order */
    for (index = 0; index < len; ++index)
    {
        a = (a + data[index]) % MOD_ADLER;
        b = (b + a) % MOD_ADLER;
    }

    return (b << 16) | a;
}

三.实现更改

因为已经找出来了文件不同的地方，所以只需要按需上传更改的部分到服务器，然后服务器做更改就可以了。

实例分析：

理论概述完毕，来点小例子子

客户端文件内容是：

taohuiissoman

而服务器的文件内容是：

itaohuiamsoman

首先，客户端开始分块并计算出MD5和Alder32值。

如上图，像taoh是一块，对taoh分别计算出MD5和alder32值。以此类推，最后一个n字母不足4位保留。于是，客户端把计算出的MD5和alder32按顺序发出，最后发出字符n。

服务器收到后，先把自己保存的File.2的内容按4字节划分。

划分出itao、huia、msom、an，当然，这些串的Alder32值肯定无法从File.1里划分出的：taoh、uiis、soma、n找出相同的。于是向后移一个字节，从t开始继续按4字节划分。

从taoh上找到了alder32相同的块，接着再比较MD5值，也相同！于是记下来，跳过taoh这4个字符，看uiam，又找不到File.1上相同的块了。继续向后跳1个字节从i开始看。还是没有找到Alder32相同，继续向后移，以此类推。

到了soma，又找到相同的块了。

重复上面的步骤，直到File.2文件结束。

通过这个简单的例子，可以设想一下其他任何的增删查改功能

参考资料：http://cs.anu.edu.au/techreports/1996/TR-CS-96-05.pdf

本文链接

如何正确的终止正在运行的子线程

2012-03-21T15:08:00Z

最近开发一些东西，线程数非常之多，当用户输入Ctrl+C的情形下，默认的信号处理会把程序退出，这时有可能会有很多线程的资源没有得到很好的释放，造成了内存泄露等等诸如此类的问题，本文就是围绕着这么一个使用场景讨论如何正确的终止正在运行的子线程。其实本文更确切的说是解决如何从待终止线程外部安全的终止正在运行的线程

首先我们来看一下，让当前正在运行的子线程停止的所有方法

1.任何一个线程调用exit
2.pthread_exit
3.pthread_kill
4.pthread_cancel

下面我们一一分析各种终止正在运行的程序的方法

任何一个线程调用exit

任何一个线程只要调用了exit都会导致进程结束，各种子线程当然也能很好的结束了，可是这种退出会有一个资源释放的问题.我们知道当一个进程终止时，内核对该进程所有尚未关闭的文件描述符调用close关闭，所以即使用户程序不调用close，在终止时内核也会自动关闭它打开的所有文件。没错，标准C++ IO流也会很好的在exit退出时得到flush并且释放资源，这些东西并不会造成资源的浪费（系统调用main函数入口类似于exit(main(argc,argv))).表面上似乎所有的问题都能随着进程的结束来得到很好的处理，其实并不然，我们程序从堆上分配的内存就不能得到很好的释放，如new ,delete后的存储空间，这些空间进程结束并不会帮你把这部分内存归还给内存.(本文初稿时，因基础不牢固，此处写错，事实上无论进程这样结束，系统都将会释放掉所有代码所申请的资源，无论是堆上的还是栈上的。（感谢ZKey的指导）。这种结束所有线程（包括主线程）的方式实际上在很多时候是非常可取的，但是对于针对关闭时进行一些别的逻辑的处理（指非资源释放逻辑）就不会很好，例如我想在程序被kill掉之前统计一下完成了多少的工作，这个统计类似于MapReduce，需要去每个线程获取，并且最后归并程一个统一的结果等等场景）

pthread_exit

此函数的使用场景是当前运行的线程运行pthread_exit得到退出，对于各个子线程能够清楚地知道自己在什么时候结束的情景下，非常好用，可是实际上往往很多时候一个线程不能知道知道在什么时候该结束，例如遭遇Ctrl+C时,kill进程时，当然如果排除所有的外界干扰的话，那就让每个线程干完自己的事情后，然后自觉地乖乖的调用pthread_exit就可以了，这并不是本文需要讨论的内容，本文的情景就是讨论如何处理特殊情况。

这里还有一种方法，既然子线程可以通过pthread_exit来正确退出，那么我们可以在遭遇Ctrl+C时,kill进程时处理signal信号，然后分别给在某一个线程可以访问的公共区域存上一个flag变量，线程内部每运行一段时间（很短）来检查一下flag，若发现需要终止自己时，自己调用pthread_exit，此法有一个弱点就是当子线程需要进行阻塞的操作时，可能无暇顾及检查flag，例如socket阻塞操作。如果你的子线程的任务基本没有非阻塞的函数，那么这么干也不失为一种很好的方案。

pthread_kill

不要被这个可怕的邪恶的名字所吓倒，其实pthread_kill并不像他的名字那样威力大，使用之后，你会感觉，他徒有虚名而已

pthread_kill的职责其实只是向指定的线程发送signal信号而已，并没有真正的kill掉一个线程，当然这里需要说明一下，有些信号的默认行为就是exit，那此时你使用pthread_kill发送信号给目标线程，目标线程会根据这个信号的默认行为进行操作，有可能是exit。当然我们同时也可以更改获取某个信号的行为，以此来达到我们终止子线程的目的。

1 #define _MULTI_THREADED
2 #include <pthread.h>
3 #include <stdio.h>
4 #include <signal.h>
5 #include "check.h"
6
7 #define NUMTHREADS 3
8 void sighand(int signo);
9
10 void *threadfunc(void *parm)
11 {
12   pthread_t             self = pthread_self();
13   pthread_id_np_t       tid;
14   int                   rc;
15
16   pthread_getunique_np(&self, &tid);
17   printf("Thread 0x%.8x %.8x entered\n", tid);
18   errno = 0;
19   rc = sleep(30);
20   if (rc != 0 && errno == EINTR) {
21     printf("Thread 0x%.8x %.8x got a signal delivered to it\n",
22            tid);
23     return NULL;
24   }
25   printf("Thread 0x%.8x %.8x did not get expected results! rc=%d, errno=%d\n",
26          tid, rc, errno);
27   return NULL;
28 }
29
30 int main(int argc, char **argv)
31 {
32   int                     rc;
33   int                     i;
34   struct sigaction        actions;
35   pthread_t               threads[NUMTHREADS];
36
37   printf("Enter Testcase - %s\n", argv[0]);
38
39   printf("Set up the alarm handler for the process\n");
40   memset(&actions, 0, sizeof(actions));
41   sigemptyset(&actions.sa_mask);
42   actions.sa_flags = 0;
43   actions.sa_handler = sighand;
44
45   rc = sigaction(SIGALRM,&actions,NULL);
46   checkResults("sigaction\n", rc);
47
48   for(i=0; i<NUMTHREADS; ++i) {
49     rc = pthread_create(&threads[i], NULL, threadfunc, NULL);
50     checkResults("pthread_create()\n", rc);
51   }
52
53   sleep(3);
54   for(i=0; i<NUMTHREADS; ++i) {
55     rc = pthread_kill(threads[i], SIGALRM);
56     checkResults("pthread_kill()\n", rc);
57   }
58
59   for(i=0; i<NUMTHREADS; ++i) {
60     rc = pthread_join(threads[i], NULL);
61     checkResults("pthread_join()\n", rc);
62   }
63   printf("Main completed\n");
64   return 0;
65 }
66
67 void sighand(int signo)
68 {
69   pthread_t             self = pthread_self();
70   pthread_id_np_t       tid;
71
72   pthread_getunique_np(&self, &tid);
73   printf("Thread 0x%.8x %.8x in signal handler\n",
74          tid);
75   return;
76 }

运行输出为：

1 Output:
2
3 Enter Testcase - QP0WTEST/TPKILL0
4 Set up the alarm handler for the process
5 Thread 0x00000000 0000000c entered
6 Thread 0x00000000 0000000d entered
7 Thread 0x00000000 0000000e entered
8 Thread 0x00000000 0000000c in signal handler
9 Thread 0x00000000 0000000c got a signal delivered to it
10 Thread 0x00000000 0000000d in signal handler
11 Thread 0x00000000 0000000d got a signal delivered to it
12 Thread 0x00000000 0000000e in signal handler
13 Thread 0x00000000 0000000e got a signal delivered to it
14 Main completed

我们可以通过截获的signal信号，来释放掉线程申请的资源，可是遗憾的是我们不能再signal处理里调用pthread_exit来终结掉线程，因为pthread_exit是中介当前线程，而signal被调用的方式可以理解为内核的回调，不是在同一个线程运行的，所以这里只能做处理释放资源的事情，线程内部只有判断有没有被中断（一般是EINTR）来断定是否要求自己结束，判定后可以调用pthread_exit退出。

此法对于一般的操作也是非常可行的，可是在有的情况下就不是一个比较好的方法了，比如我们有一些线程在处理网络IO事件，假设它是一种一个客户端对应一个服务器线程，阻塞从Socket中读消息的情况。我们一般在网络IO的库里面回家上对EINTR信号的处理，例如recv时发现返回值小于0，检查error后，会进行他对应的操作。有可能他会再recv一次，那就相当于我的线程根本就不回终止,因为网络IO的类有可能不知道在获取EINTR时要终止线程。也就是说这不是一个特别好的可移植方案，如果你线程里的操作使用了很多外来的不太熟悉的类，而且你并不是他对EINTR的处理手段是什么，这是你在使用这样的方法来终止就有可能出问题了。而且如果你不是特别熟悉这方面的话你会很苦恼，“为什么我的测试代码全是ok的，一加入你们部门开发的框架进来就不ok了，肯定是你们框架出问题了”。好了，为了不必要的麻烦，我最后没有使用这个方案。

pthread_cancel

这个方案是我最终采用的方案，我认为是解决这个问题，通用的最好的解决方案，虽然前面其他方案的有些问题他可能也不好解决，但是相比较而言，还是相当不错的

pthread_cancel可以单独使用，因为在很多系统函数里面本身就有很多的断点，当调用这些系统函数时就会命中其内部的断点来结束线程，如下面的代码中，即便注释掉我们自己设置的断点pthread_testcancel()程序还是一样的会被成功的cancel掉，因为printf函数内部有取消点（如果大家想了解更多的函数的取消点情况，可以阅读《Unix高级环境编程》的线程部分）

1 #include <pthread.h>
2 #include <stdio.h>
3 #include<stdlib.h>
4 #include <unistd.h>
5 void *threadfunc(void *parm)
6 {
7   printf("Entered secondary thread\n");
8   while (1) {
9     printf("Secondary thread is looping\n");
10     pthread_testcancel();
11     sleep(1);
12   }
13   return NULL;
14 }
15
16 int main(int argc, char **argv)
17 {
18   pthread_t             thread;
19   int                   rc=0;
20
21   printf("Entering testcase\n");
22
23   /* Create a thread using default attributes */
24   printf("Create thread using the NULL attributes\n");
25   rc = pthread_create(&thread, NULL, threadfunc, NULL);
26   checkResults("pthread_create(NULL)\n", rc);
27
28   /* sleep() is not a very robust way to wait for the thread */
29   sleep(1);
30
31   printf("Cancel the thread\n");
32   rc = pthread_cancel(thread);
33   checkResults("pthread_cancel()\n", rc);
34
35   /* sleep() is not a very robust way to wait for the thread */
36   sleep(10);
37   printf("Main completed\n");
38   return 0;
39 }

输出：

Entering testcase
Create thread using the NULL attributes
Entered secondary thread
Secondary thread is looping
Cancel the thread
Main completed

POSIX保证了绝大部分的系统调用函数内部有取消点，我们看到很多在cancel调用的情景下，recv和send函数最后都会设置pthread_testcancel()取消点，其实这不是那么有必要的，那么究竟什么时候该pthread_testcancel()出场呢？《Unix高级环境编程》也说了，当遇到大量的基础计算时（如科学计算），需要自己来设置取消点。

ok，得益于pthread_cancel，我们很轻松的把线程可以cancel掉，可是我们的资源呢？何时释放...

下面来看两个pthread函数

1.void pthread_cleanup_push(void (*routine)(void *), void *arg);
2.void pthread_cleanup_pop(int execute);

这两个函数能够保证在 1函数调用之后，2函数调用之前的任何形式的线程结束调用向pthread_cleanup_push注册的回调函数
另外我们还可通过下面这个函数来设置一些状态

int pthread_setcanceltype(int type, int *oldtype);

Cancelability	Cancelability State	Cancelability Type
disabled	PTHREAD_CANCEL_DISABLE	PTHREAD_CANCEL_DEFERRED
disabled	PTHREAD_CANCEL_DISABLE	PTHREAD_CANCEL_ASYNCHRONOUS
deferred	PTHREAD_CANCEL_ENABLE	PTHREAD_CANCEL_DEFERRED
asynchronous	PTHREAD_CANCEL_ENABLE	PTHREAD_CANCEL_ASYNCHRONOUS

当我们设置type为PTHREAD_CANCEL_ASYNCHRONOUS时，线程并不会等待命中取消点才结束，而是立马结束

好了，下面贴代码：

1 #include <pthread.h>
2 #include <stdio.h>
3 #include <stdlib.h>
4 #include <unistd.h>
5 #include <errno.h>
6 int footprint=0;
7 char *storage;
8 void freerc(void *s)
9 {
10    free(s);
11    puts("the free called");
12 }
13
14 static void checkResults(char *string, int rc) {
15   if (rc) {
16     printf("Error on : %s, rc=%d",
17            string, rc);
18     exit(EXIT_FAILURE);
19   }
20   return;
21 }
22
23 void *thread(void *arg) {
24   int           rc=0, oldState=0;
25   rc = pthread_setcancelstate(PTHREAD_CANCEL_DISABLE, &oldState);   //close the cancel switch
26   checkResults("pthread_setcancelstate()\n", rc);
27   if ((storage = (char*) malloc(80)) == NULL) {
28     perror("malloc() failed");
29     exit(6);
30   }
31    rc = pthread_setcancelstate(PTHREAD_CANCEL_ENABLE,&oldState);   //open the cancel  switch
32    checkResults("pthread_setcancelstate(2)\n", rc);
33 /* Plan to release storage even if thread doesn't exit normally */
34
35   pthread_cleanup_push(freerc, storage);   /*the free is method here   you can use your own method here*/
36
37   puts("thread has obtained storage and is waiting to be cancelled");
38   footprint++;
39   while (1)
40     {
41          pthread_testcancel();   //make a break point here
42            //pthread_exit(NULL);    //test exit to exam whether the freerc method called
43             sleep(1);
44     }
45
46   pthread_cleanup_pop(1);
47 }
48
49 main() {
50   pthread_t thid;
51  void                 *status=NULL;
52
53   if (pthread_create(&thid, NULL, thread, NULL) != 0) {
54     perror("pthread_create() error");
55     exit(1);
56   }
57
58   while (footprint == 0)
59     sleep(1);
60
61   puts("IPT is cancelling thread");
62
63   if (pthread_cancel(thid) != 0) {
64     perror("pthread_cancel() error");
65     sleep(2);
66     exit(3);
67   }
68
69   if (pthread_join(thid, &status) != 0) {
70     if(status != PTHREAD_CANCELED){
71         perror("pthread_join() error");
72         exit(4);
73     }
74   }
75  if(status == PTHREAD_CANCELED)
76     puts("PTHREAD_CANCELED");
77
78  puts("main exit");
79 }

本文链接

MongoDB源码概述——启动处理

2012-03-07T13:21:00Z

在启动MongoDB后，程序会对相应的参数，上次遗留的锁文件，日志文件等等进行相应的处理，同时也会开启一些支撑其他部分运行的服务线程，为了精读MongoDB的代码，领会其全局设计理念，所以我对这些不是特别核心的部分，也通过博文给自己来做一个总结，方便自己以后查阅。

程序在mian函数里进行了对输入参数的所有处理，程序使用Boost库实现了跨平台的命令行参数的兼容性，这部分的代码非常庞大，也非常的乱，所以也没有必要太过记载，在main函数的底部进行了initAndListen(cmdLine.port, appsrvPath);调用，这个函数就是我们的重点部分。

在void _initAndListen(int listenPort, const char *appserverLoc = NULL)内函数首先进行了一些运行环境的相关检验，如：判断当前系统是不是32bit系统：bool is32bit = sizeof(int*) == 4;接着输出一些版本信息(这部分代码就不贴了）后面进行了acquirePathLock()方法的调用。

void acquirePathLock() {

string name = ( boost::filesystem::path( dbpath ) / "mongod.lock" ).native_file_string();

        bool oldFile = false;
        //oldFile为true的概念是存在mongod.lock并且它的filesize大于0,。正常结束的进程会将mongodb.lock大小设置为0（包括CTRL+C）
        if ( boost::filesystem::exists( name ) && boost::filesystem::file_size( name ) > 0 ) {
            oldFile = true;
        }
        // we check this here because we want to see if we can get the lock
        // if we can't, then its probably just another mongod running

        lockFile = open( name.c_str(), O_RDWR | O_CREAT , S_IRWXU | S_IRWXG | S_IRWXO );
        if( lockFile <= 0 ) {
            uasserted( 10309 , str::stream() << "Unable to create / open lock file for lockfilepath: " << name << ' ' << errnoWithDescription());
        }
        if (flock( lockFile, LOCK_EX | LOCK_NB ) != 0) {   //man 2 flock 查看参数
            close ( lockFile );//若另一个mongod程序锁住了该文件，则flock LOCK_EX会失败（即返回结果！=0），抛出下面的异常，此处保证了一个dbpath不能被两个mongod程序同时打开
            lockFile = 0;
            uassert( 10310 ,  "Unable to acquire lock for lockfilepath: " + name,  0 );
        }

        if ( oldFile ) {
            //若上次异常结束
            string errmsg;
            if (cmdLine.dur) {
                //若开启了-dur属性
                if (!dur::haveJournalFiles()) {

                    vector<string> dbnames;
                    getDatabaseNames( dbnames );//获取同一目录下的所有xx.ns的xx，存入dbnames

                    if ( dbnames.size() == 0 ) {//在没有任何xx.ns的情况下，不需要修复，所以也就不需要处理了，直接让程序继续运行
                        // this means that mongod crashed
                        // between initial startup and when journaling was initialized
                        // it is safe to continue
                    }
                    else {
                        errmsg = str::stream()
                            << "************** \n"
                            << "old lock file: " << name << ".  probably means unclean shutdown,\n"
                            << "but there are no journal files to recover.\n"
                            << "this is likely human error or filesystem corruption.\n"
                            << "found " << dbnames.size() << " dbs.\n"
                            << "see: http://dochub.mongodb.org/core/repair for more information\n"
                            << "*************";
                    }

                }
            }
            else {
                //若没有开启了-dur属性又存在.lock文件，则给出错误信息到errmsg
                errmsg = str::stream()
                         << "************** \n"
                         << "old lock file: " << name << ".  probably means unclean shutdown\n"
                         << "recommend removing file and running --repair\n"
                         << "see: http://dochub.mongodb.org/core/repair for more information\n"
                         << "*************";
            }
            //若有上面errmsg有任何错误信息，则停止程序
            if (!errmsg.empty()) {
                cout << errmsg << endl;
                close ( lockFile );

                lockFile = 0;
                uassert( 12596 , "old lock file" , 0 );
            }
        }

        // Not related to lock file, but this is where we handle unclean shutdown
        if( !cmdLine.dur && dur::haveJournalFiles() ) {//如果竟不是-dur模式启动，但又有Journal日志文件，则异常退出，因为无法处理未持久化的数据
            cout << "**************" << endl;
            cout << "Error: journal files are present in journal directory, yet starting without --dur enabled." << endl;
            cout << "It is recommended that you start with journaling enabled so that recovery may occur." << endl;
            cout << "Alternatively (not recommended), you can backup everything, then delete the journal files, and run --repair" << endl;
            cout << "**************" << endl;
            uasserted(13597, "can't start without --dur enabled when journal/ files are present");
        }
        uassert( 13342, "Unable to truncate lock file", ftruncate(lockFile, 0) == 0);
        writePid( lockFile );//将进程号写入了mongod.lock文件
        fsync( lockFile );

    }

对于这段代码的逻辑，我这里就不罗嗦了，我画了一张流程图，我相信图片比代码更容易让人理解。

oldFile为true的概念是存在mongod.lock并且它的filesize大于0,对于这一点可能大家不太容易理解filesize在这个特定语境的意思，我们来看在db.cpp里注册的信号处理函数就明白了。

void ctrlCTerminate() {

log() << "got kill or ctrl-c signal, will terminate after current cmd ends" << endl;
        Client::initThread( "ctrlCTerminate" );
        exitCleanly( EXIT_KILL );
    }

在exitCleanly中最后调用了shutdownServer函数，负责所有的扫尾工作，对于我们关注的mongo.lock的处理部分如下：

if ( lockFile ) {

log() << "shutdown: removing fs lock..." << endl;
            if( ftruncate( lockFile , 0 ) )  //man  ftruncate  设置文件大小为0
                log() << "couldn't remove fs lock " << errnoWithDescription() << endl;
            flock( lockFile, LOCK_UN );
        }

也就是是，只要是正常退出（包括CTRL+C)，mongo.lock的大小就会为0，所以可以通过它来判断上次服务此是怎么结束的。

在_initAndListen 方法中还进行了如下调用：

FileAllocator::get()->start();

一看到这种调用入口，就可以推测出这里肯定使用的是单例模式

在我们调用的start方法中，FileAllocator创建了一个单独的线程来专门运行其run方法

1 void FileAllocator::start() {
2 boost::thread t( boost::bind( &FileAllocator::run , this ) );

}

FileAllocator::run方法类似于一个单独的服务的线程，专门提供创建指定大小文件的任务。

当系统的其他运行部分需要使用它的服务的时候，只需要在那个线程调用 FileAllocator::requestAllocation函数

这个函数会把用户想要创建的文件名放入list< string > _pending 中存储，将其文件名和大小对应关系存入mutable map< string, long >中

同时这个函数还是用了boost::condition来进行同步操作（类似于生产者消费者），在run函数中，放文件创建需求列表（_pending)为空时会进行等待

if ( fa->_pending.size() == 0 )

fa->_pendingUpdated.wait( lk.boost() );

这样就防止了无限循环while所带来了损耗CPU时间的弊端

若需求列表中有需要创建的item了就会调用系统API进行文件创建

long fd = open(name.c_str(), O_CREAT | O_RDWR | O_NOATIME, S_IRUSR | S_IWUSR);

通过上面的调用，文件是被创建了，可是需求却没有得到满足，因为我们创建的文件不是指定大小的，这里有必要解释一下为什么需要先创建指定大小的文件，因为对于数据库文件来说，操作很有可能是非常频繁，这就对我存数据的文件提出了要求，我们总是希望数据库文件在磁盘上能得到一块连续的空间（就像内存分配一样），这样对文件进行读写的时候，文件的fragments比较少，读起来也会比较快（系统API级别的，不可控的），所以一般希望能够Handles allocation of contiguous files on disk

下面来看mongoDB是怎么处理这个问题的：

在调用open创建文件后会进行 ensureLength( fd , size )调用，在ensureLength内部会进行下面的循环

1             char* buf = buf_holder.get();
2             memset(buf, 0, z);
3             long left = size;
4             while ( left > 0 ) {
5                 long towrite = left;
6                 if ( towrite > z )
7                     towrite = z;
8
9                 int written = write( fd , buf , towrite );
10                 uassert( 10443 , errnoWithPrefix("FileAllocator: file write failed" ), written > 0 );
11                 left -= written;

}

看完之后你会不会很惊讶，居然创建指定大小的文件是通过while循环来做的，没错，不管你有没有惊讶，反正我惊讶了。

后来仔细一想，其实这也是一个还不错的方案，毕竟暂时我还没有发现任何可以创建指定大小，空间连续的文件的方法，虽然用上面的方法不能保证空间就一定连续，但是集中在一个时间在占用文件大小，比需要时每次再去写一下，fragments会少很多。

Ok,现在总结一下，FileAllocator的职责就是尽量创建fragments少的指定大小的文件，实现方法为，一个线程专门用于提供创建文件和填充到指定大小的服务，其他的线程调用requestAllocation函数进行需求注册，服务线程获取需求，然后工作，其实也可以理解为一种生产者消费者模式，其他的线程生产出需求（文件名，大小），这可以理解为生产者，而服务线程可以理解为消费者，只有需求到达时才运行，否则等待....

本文链接

MongoDB源码概述——日志

2012-03-02T14:13:00Z

本篇文章主要介绍MongoDB的日志模块以及数据持久化存储模块的代码实现方式。大家也许会惊讶，为什么日志模块和持久化存储模块会放到一篇文章来总结。嘿嘿，在别的系统，可能这两个模块联系不是特别大，可是这MongoDB ,这两个模块还真不能分开来讲。这是怎么回事呢？请听我娓娓道来…

通常说来,MongoDB具有三个日志模块，

Log
Journal
Oplog

Log: 位于 log.h，它主要负责用户日志文件，这和我们普通系统的日志系统没有什么区别，作用也就是记录系统的一些重要流程，然后持久化到log文件。这个log文件可以通过系统启动参数"--logpath".

Journal: 位于dur.h，通过启动参数"--dur"启动该模块功能。主要用于解决因系统宕机时，内存中的数据未写入磁盘而造成的数据丢失(为什么数据会被放到内存做存储而不是直接对外存上的文件进行操作呢？这一点与MongoDB的存储机制有关，稍后会讲到)。其机制主要是通过log方式定时将操作日志（对数据库有更改的操作，查询不在记录范围之类）记录到dbpath的命名为journal文件夹下，这样当系统再次重启时从该文件夹下恢复丢失的数据。

Oplog :当部署应用于生产的健壮的服务器时，需要对服务器进行同步备份，MongoDB为解决这一问题提出了复制集(Replica sets)模式，而Oplog 的作用则主要是负责记录写服务器（一个复制集内只有一台服务器可写，多台备份服务器可读）上所有对数据的更改（查询等对数据库不产生更改的操作不会被记录）,这样，复制集内的其他读扩展（即用于备份的机器和分散读压力的服务器）的服务器通过获取Oplog 就可以进行差异同步了。

本文主要是介绍日志和持久化存储，以及他们之间的关系。所以本文就不对Oplog做过多的说明，后续文章讲到复制集模块时，我一定会写上。本文的主要重点还是分析Journal以及持久化的实现，所以，对于Log模块，我也就只是简单的概括一下了。

Log模块：

当我们启动MongoDB，对Log模块的调用流程如下:

Main(...)->addWindowsOptions(...)->initLogging(...)->loggingManager.start(...);

之后会调用这样的代码来设置stdout的输出目标

FILE* tmp = freopen(_path.c_str(), (_append ? "a" : "w"), stdout);

又因为static的logfile指针指向stdout

FILE* Logstream::logfile = stdout;

所以在Logstream内最后数据会被flush到stdout，即系统所指定的目的地.

在log.h下有如下定义：

1    enum LogLevel {  LL_DEBUG , LL_INFO , LL_NOTICE , LL_WARNING , LL_ERROR , LL_SEVERE };
2    inline Nullstream& log( int level ) {
3         if ( level > logLevel )
4             return nullstream;
5         return Logstream::get().prolog();
6     }
7
8     inline Nullstream& log() {
9         return Logstream::get().prolog();
10     }

又因为Logstream重载了一些基本的流符号：

Logstream& operator<<(const char *x) { ss << x; return *this; }

Logstream& operator<<(const string& x) { ss << x; return *this; }

Logstream& operator<<(const StringData& x) { ss << x.data(); return *this; }

Logstream& operator<<(char *x) { ss << x; return *this; }

…

Logstream& operator<< (ostream& ( *_endl )(ostream&)) {

ss << '\n';

flush(0);

return *this;

}

Logstream& operator<< (ios_base& (*_hex)(ios_base&)) {

ss << _hex;

return *this;

}

所以，我们可以轻松的使用下面的操作来记录我们的日志。

log() << "WARNING: alloc() failed after allocating new extent. lenWHdr: "<<endl;

我不知道大家是否喜欢我这样的分析模式，我是挺喜欢的，节奏快，很直接，很靠谱！

这里做一下简要说明<<重载运算符方法将要输出的日志放入stringstream的,接着调用<<endl时，触发上面列出来的Logstream& operator<< (ostream& ( *_endl )(ostream&))方法，间接调用flush(0)

void Logstream::flush(Tee *t)方法的职责就是将stringstream内缓存的所有日志进行持久化到logfile.因为flush这部分的代码也非常的简洁易懂，所以这里就不贴了。至此用户日志也被写到了外存上，基本功能已经完成。

在flush中另外值得注意是与Tee相关的代码　

if( t ) t->write(logLevel,out);

if ( globalTees ) {

for ( unsigned i=0; i<globalTees->size(); i++ )

(*globalTees)[i]->write(logLevel,out);

}

关于Tee的定义：

class Tee {

public:

virtual ~Tee() {}

virtual void write(LogLevel level , const string& str) = 0;

};

所以我们可以很清晰的认识到，实际上Tee的职责是订阅日志信息（观察者设计模式），任何Tee的派生类都可以实现在不影响现有日志的情景下将日志额外的记录到其他任何地方。例如远程日志.或者在服务器很多的情况下，收集各个服务器的用户日志放入数据库，以供管理员查看.

Journal模块：

实际上在MongoDB中，Journal\Durability是一个很大的模块，牵扯到的东西也是非常之多，他的设计初衷是为了使用日志的方式来提高单机数据的可靠性，在1.7版本的最新分支上首次出现了这个部分.具体他的职责可以用一句话来概括：

通过log方式定时将操作日志（对数据库有更改的操作，查询不在记录范围之类）记录到dbpath的命名为journal文件夹下，这样当系统再次重启时从该文件夹下恢复丢失的数据。

根据其完成的功能，我们可以将这个部分的实现概括为以下几个问题：

何时调用
如何记录用户操作
如何序列化用户操作并持久化
如何根据现有Journal日志恢复数据

下面我们来一一根据源码分析其重要步骤：

一.何时调用

当我们需要更改数据库时，需要记录下用户的操作以及用户更改后的数据,这些记录的数据将是进行恢复时的数据源。举一个例子，我们向数据库插入一条记录的时候，我们需要记录用户的操作以及操作的数据，我截取了这部分代码，如下：

r = (Record*) getDur().writingPtr(r, lenWHdr);//持久化插入记录信息

...

if( obuf )

memcpy(r->data, obuf, len);//直接拷贝数据到记录字段

我们来看DurableImpl内的几个重要方法：

//告诉系统我正在往x位置写入数据（更改或插入时丢会调用）

void* writingPtr(void *x, unsigned len);

//告诉系统我创建了一个文件

void createdFile(string filename, unsigned long long len);

其实调用上两个函数的潜台词就是，我现在干了什么事，你给我把他完整的记录下来，如果我这件事没有最终被保存到磁盘的话，我就需要你这个负责记录的模块拿出原来所做的记录，我来进行恢复操作，以确保数据万无一失！

二.如何记录用户操作

在这个模块，用户的操作类型实际上可以归类为两种，一种是基本写操作，一种是非基本写操作。对数据的新增和修改等都可以认为是写操作，而类似与创建文件（FileCreatedOp）,删除数据库（DropDbOp）操作都是非基本写操作，这类操作建模为DurOp.最终这两种操作都会在CommitJob:: note()与 CommitJob::noteOp()进行内存存储。

基本写操作会被D结构体封装,我们来看下他的结构：

struct D {

void *p;//用户更改的数据源首地址

unsigned len;//用户更改的数据长度

static void go(const D& d);

};

基本写记录会被存储到Writes类在CommitJob类的实例_wi,继而存储到TaskQueue<D>在Writes类的实例_deferred.

非基本写记录会被存储到Writes类的vector< shared_ptr<DurOp> > _ops;

这个流程有很多个类参与，下面用两张顺序图来总结这一流程。

调用getDur().writingPtr的时序图

调用getDur().createdFile的时序图

至此为止,用户操作日志在内存的记录操作就完成了。接下来要讲到如何序列化内存中的记录，以备持久化到磁盘.

今日至此，下面两点下次结合其他的文章一起写。

如何序列化用户操作并持久化

如何根据现有Journal日志恢复数据

后会有期......

本文链接

树状数组

2011-09-10T08:11:00Z

在一个数组中。若你需要频繁的计算一段区间内的和，你会怎么做？，最最简单的方法就是每次进行计算，但是这需要O(N)的时间复杂度，如这个需求非常的频繁，那么这个操作就会占用大量的CPU时间，进一步想一想，你有可能会想到使用空间换取时间的方法，把每一段区间的值一次记录下来，然后存储在内存中，将时间复杂度降低到O（1），的确，对于目前的这个需求来说，已经能够满足时间复杂度上的要求，尽管带来了线性空间复杂度的提升.

但若是我们的源数据需要频繁的更改怎么办？使用上面的方案，我们需要大量的更新我们保存到内存中的区间和，而且这中间的很多更新的影响是重叠的，我们需要重复计算。例如对于数组array[10],更新了array[4]值，需要更新区间[4,5],[4,5,6],在更新[4,5,6]需要又一次的计算[4,5]，这样的更新带来了非常多的重复计算，为了解决这一问题，树状数组应运而生了。

当要频繁的对数组元素进行修改,同时又要频繁的查询数组内任一区间元素之和的时候,可以考虑使用树状数组.树状数组是一种非常优雅的数据结构.先来看看一张树状结构的图片

图中C[1]的值等于A[1]，C[2]的值等于C[1]+A[2]=A[1]+a[2],C[4]的值=C[2]+C[3]=A[1]+A[2]+A[3]+A[4],假设我们现在需要更改元素a[2],那么它将只影响到得c数组中的元素有c[2],c[4],c[8],我们只需要重新计算这几个值即可，减少了很多重复的操作。这就是树状结构大致的一个存贮示意图，下面看看他的定义：

假设a[1...N]为原数组,定义c[1...N]为对应的树状数组:
c[i] = a[i - 2^k + 1] + a[i - 2^k + 2] + ... + a[i] （其中k为i的二进制表示末尾0的个数）

下面枚举出i由1...5的数据，可见正是因为上面的a[i - 2^k + 1]...a[i]的计算公式保证了我们C数组的正确意义，至于证明过程，大家可以翻阅相关资料..

基本操作：

对于C[i]=a[i - 2^k + 1]...a[i]的定义中，比较难以逐磨的k，他的值等于i这个数的二进制表示末尾0的个数.如4的二进制表示0100,此时k就等于2，而实际上我们还会发现2^k就是前一位的权值,即0100中,2^2=4，刚好是前一位数1的权值.所以所以2^k可以表示为n&(n^(n-1))或更简单的n&(-n)，例如：

为了表示简便，假设现在一个int型为4位,最高位为符号位

int i=3&(-3); 此时i=1，3的二进制为0011,-3的二进制为1101(负数存的是补码）所以0011&1101=1

int j=4&(-4); 此时j=4，理由同上..

所以计算2^k我们可以用如下代码：

1 int lowbit(int x)//计算lowbit
2 {
3 return x&(-x);
4 }

求和操作：

在上面的示意图中，若我们需要求sum[1..7]个元素的和，仅需要计算c[7]+c[6]+c[4]的和即可，究竟时间复杂度怎么算呢？一共要进行多少次求和操作呢？

求sum[1..k],我们需查找k的二进制表示中1的个数次就能得到最终结果，具体为什么，请见代码i-=lowbit(i)注释

1 int sum(int i)//求前i项和
2 {
3     int s=0;
4     while(i>0)
5     {
6         s+=c[i];
7         i-=lowbit(i); //这一步实际上等价于将i的二进制表示的最后一个1剪去，再向前数当前1的权个数（例子在下面），
8                       //而n的二进制里最多有log(n)个1，所以查询效率是log(n)
9                       //在示意图上的操作即可理解为依次找到所有的子节点
10     }
11     return s;
12 }

以求sum[1..7]为例,二进制为0111,右边第一个1出现在第0位上,也就是说要从a[7]开始向前数1个元素(只有a[7]),即c[7];

然后将这个1舍掉,得到6,二进制表示为0110,右边第一个1出现在第1位上,也就是说要从a[6]开始向前数2个元素(a[6],a[5]),即c[6];

然后舍掉用过的1,得到4,二进制表示为0100,右边第一个1出现在第2位上,也就是说要从a[4]开始向前数4个元素(a[4],a[3],a[2],a[1]),即c[4].

所以s[7]=c[7]+c[6]+c[4]

给源数组加值操作:

在上面的示意图中，假设更改的元素是a[2],那么它影响到得c数组中的元素有c[2],c[4],c[8]，我们只需一层一层往上修改就可以了,这个过程的最坏的复杂度也不过O(logN);

void add(int i,int val)
{
    while(i<=n)
    {
        c[i]+=val;
        i+=lowbit(i); //i+（i的二进制中最后一个1的权值,即2^k）,在示意图上的操作即为提升一层，到上一层的节点.
                           //这个过程实际上也只是一个把末尾1后补0的过程（例子在下面）
    }
}

以修改a[2]元素为例，需要修改c[2],2的二进制为0010,末尾补0为0100,即c[4]

4的二进制为0100，在末尾补0为1000即c[8]。所以我们需要修改的有c[2],c[4],c[8]

POJ上面有一个这方面的水题，可以帮助理解 http://poj.org/problem?id=2352

解题报告http://hi.baidu.com/acmerskycoding/blog/item/40af1b2585dd310a4c088d95.html

本文链接

离线应用——业务数据同步方案探讨

2011-07-13T08:48:00Z

目标：

大家可以设想这样一个情景，公司已经部署信息化，且很多办公流程已经挪到线上正在运营的系统来解决，这带给企业的员工非常大的便利，节省办公时间，提高办公效率，可是我们把所有的流程和数据都放到了公司服务器，一旦离开了公司，我们就相当于和我们所有的办公环境脱离了，不再可以查看公司系统上的运营数据，不再可以进行添加删除等等一系列操作。如果你最近的工作非常的多，你在有限的正常办公时间内不能完成，那怎么办，只有在办公室奋战，叫苦不迭的夜晚办公室生活就开始了.

离线应用生来就是为了解决这样的问题，针对上面所列举的情况，你不需要在办公室进行奋战，你要做的只有

1.将线上系统某个列表（或存储结构）的数据按需选择同步到本地

2.回到家，利用闲暇时间，打开离线应用，对数据进行操作

3.第二天回到公司，同步数据到公司服务器

说了这么多，我们的目的只有一个：实现离线办公

实现方案：

我们将整个离线应用分为两块

1.业务数据同步到本地

2.本地提交到业务系统

对于中间支持用户怎么去操作数据，不是我们这里讨论的重点，这也是随业务逻辑而变的，一般都会在功能上做成和线上的系统一样

1.业务数据同步到本地

将云上的业务上的数据按需同步到本地并不是什么难的操作，但是这里也不容小觑

技术实现要点：

能够按需选择数据同步到本地，为了让用户不用花大量的时间在等待同步数据到本地，我们可以采用由用户选择数据的同步机制，有选择的将真正对用户有用的数据同步到本地，当然我们在代码逻辑中，还需要记住用户的这些选择，并持久化，为用户回到公司进行数据提交提供处理基础
离线客户端数据暂存器能够实现数据的持久化

业务数据同步到本地除了上面涉及到的，实际上我们还必须解决差异同步问题

虽然我们在同步业务数据到本地的时候，用户可以按需进行选择，但是如果用户当前选择的数据，有若干数据已经在本地有副本了，这些应该怎么处理呢？差异同步的实现不知道大家有没有比较好的方案，我这里提供一点拙见

最笨的方法就是遍历然后依次判断个属性是否相等，若发现在本地有副本，则跳到下一个业务数据条目，继续运行，
使用version法，给每个业务数据条目都加上一个version，对业务数据条目的任何更改都会引起version++，这样我们就可以通过判断version来确定,而且我们可以使用截获事件的手段来避免version给我们带来业务逻辑上的任何变化

2.提交数据到业务系统

这里主要是员工回到公司后，系统对员工已经在线下所作的更改提交到业务系统，产生效果

技术实现要点：

找到那些已经被更改的数据，我们这里拟采用“已更改数据”存储模块来标识用户已经做了更改的数据条目，这样可以获得更快的速度，我们可以在最短的时间找到哪些数据做了更改
提交到服务器，在服务器上找到那些已更改的数据条目，应用用户最新的处理结果，若在用户离线之后，别的用户对线上的数据做了一些修改，我们应该怎么处理呢？我们现在暂定的一个原则就是以用户最后更改为最新数据，当然，这方面确实会有一点点不妥，不知道大家有没有什么比较好的方案。

本文链接

算法系列总结：分而治之——分治算法

2011-06-18T08:11:00Z

分治算法的基本思想是将一个规模为N的问题分解为K个规模较小的子问题，这些子问题相互独立且与原问题性质相同。求出子问题的解，就可得到原问题的解。

分治法解题的一般步骤：

（1）分解，将要解决的问题划分成若干规模较小的同类问题；

（2）求解，当子问题划分得足够小时，用较简单的方法解决；

（3）合并，按原问题的要求，将子问题的解逐层合并构成原问题的解。

一言以蔽之：分治法的设计思想是，将一个难以直接解决的大问题，分割成一些规模较小的相同问题，以便各个击破，分而治之。

在认识分治之前很有必要先了解一下递归，当然，递归也是最基本的编程问题，一般接触过编程的人都会对递归有一些认识.为什么要先了解递归呢？你看，根据上面所说的，我们就要将一个问题分成若干个小问题，然后一一求解并且最后合并，这就是一个递归的问题，递归的去分解自身，递归的去解决每一个小问题，然后合并…

关于递归,这里举一个最简单的例子，求N！；

我们只需要定义函数

int calculate(int n)
{
if(n==1)
return 1;
else
return n*calculate(n-1); //调用自身…
}

好了，有了递归的铺垫，我们下来来看一看一个分治算法的问题，归并排序问题…

基本思想：

将待排序元素分成大小大致相同的2个子集合(递归直到最小的排序单元），分别对2个子集合进行排序，最终将排好序的子集合合并成为所要求的排好序的集合。

下面我们用一张图来展示整个流程,最下面的（姑且叫他第一层）是原始数组分成了8个最小排序问题，各自只有一个元素，故不需要排序，大家可以看到，我们通过分而治之的思想把对最初数组的排序分为了若干个只有一个元素的小数组的排序,然后第二层,我们进行了合并，将每两个最小排序结果合并为有两个元素的数组,然后逐层往上进行合并，就有了最后的结果…

下面我们来看一下这个算法的具体实现，下面的MERGE-SORT (A, p, r)表示对数组A[p->r]的排序过程.其中p->r代表从p到r.

MERGE-SORT (A, p, r)

1. IF p < r // 进行A[p->r]的排序过程自然需要p<r的前提条件

2. THEN q = [(p + r)/2] // 将当前的排序问题一分为二，分别进行处理

3. MERGE-SORT (A, p, q) //继续递归看能不能将问题继续一分为二，处理A[p->q]的排序

4. MERGE-SORT (A, q + 1, r) // 继续递归看能不能将问题继续一分为二处理A[q+1->r]的排序

5. MERGE (A, p, q, r) // 合并当前结果

到这里，分治算法的精髓已经出来了，我们通过递归将问题进行分解到足够小…继而进行结果计算…然后再将结果合并.

下面来处理一下边角料的工作，呵呵，让大家看到一个完整的归并排序的例子，整个算法总结系列我都没有很好的使用伪代码，而是使用我认为广泛使用的C语言代码来进行代码诠释.实际上，描述算法最好还是使用伪代码比较好，这里我对我前面的四篇文章没有使用伪代码而小小的鄙视一下自己，太不专业了..呵呵

以下算法MERGE (A, p, q, r )表示合并A[p->q]和A[q+1->r]这两个已经排序好的数组

MERGE (A, p, q, r )

1.      n₁ ← q − p + 1                                                          //计算A[p->q]的长度
2.      n₂ ← r − q                                                                //计算A[q+1->r]的长度
3.      Create arrays L[1 . . n₁ + 1] and R[1 . . n₂ + 1]       //创建两个数组
4.      FOR i ← 1 TO n₁
5.            DO L[i] ← A[p + i − 1]
6.      FOR j ← 1 TO n₂
7.            DO R[j] ← A[q + j ]        //4-7行是将原数组中A[p->r]的元素取出到新创建的数组，我们的操作是基于临时数组的操作
8.      L[n₁ + 1] ← ∞
9.      R[n₂ + 1] ← ∞                   //8-9行设置界限..
10.    i ← 1
11.    j ← 1
12.    FOR k ← p TO r
13.         DO IF L[i ] ≤ R[ j]
14.                THEN A[k] ← L[i]
15.                        i ← i + 1
16.                ELSE A[k] ← R[j]
17.                        j ← j + 1                //12-17行进行排序合

这里我还是提供一个具体的实现，请见下面的代码

C语言代码

关于代码注释，请见博客上面的伪代码注释..
#include<stdio.h>
int L[100],R[100];
void merge(int numbers[],int left, int mid, int right)
        {
            int n1=mid-left+1;
            int n2=right-mid;
            int i,j,k;
            for(i=1;i<=n1;i++)
             L[i]=numbers[left+i-1];
            for( j=1;j<=n2;j++)
             R[j]=numbers[mid+j];
            L[n1+1]=99999;
            R[n2+1]=99999;

            i=1;
            j=1;

            for(k=left;k<=right;k++)
            if(L[i]<=R[j])
               {
                   numbers[k]=L[i];
                   i++;
                   }
                 else
                  {
                       numbers[k]=R[j];
                       j++;
                  }
        }

void mergeSort(int numbers[],int left, int right)

{
    if(left<right)
    {
                int mid;
            mid = (right + left) / 2;
            mergeSort(numbers, left, mid);
            mergeSort(numbers, mid+1, right);
            merge(numbers,left, mid, right);
        }

}

int main()
{
    int numbers[]={5,2,4,6,1,3,2,6};
    mergeSort(numbers,0,7);
    for(int i=0;i<8;i++)
    printf("%d",numbers[i]);
    }

C#代码

class Program
    {

        static int[] L=new int[100];
        static int[] R=new int[100];
static void merge(int[] numbers,int left, int mid, int right)
        {
            int n1=mid-left+1;
            int n2=right-mid;
            int i,j,k;
            for(i=1;i<=n1;i++)
             L[i]=numbers[left+i-1];
            for( j=1;j<=n2;j++)
             R[j]=numbers[mid+j];
            L[n1+1]=99999;
            R[n2+1]=99999;

            i=1;
            j=1;

            for(k=left;k<=right;k++)
            if(L[i]<=R[j])
               {
                   numbers[k]=L[i];
                   i++;
                   }
                 else
                  {
                       numbers[k]=R[j];
                       j++;
                  }
        }

static void mergeSort(int[] numbers,int left, int right)

{
    if(left<right)
    {
           int mid;
            mid = (right + left) / 2;
            mergeSort(numbers, left, mid);
            mergeSort(numbers, mid+1, right);
            merge(numbers,left, mid, right);
        }

}

        public static void Main(string[] args)
        {
        int[] numbers={5,2,4,6,1,3,2,6};
        mergeSort(numbers,0,7);
        for(int i=0;i<8;i++)
        Console.Write(numbers[i]);


            // TODO: Implement Functionality Here

            Console.Write("Press any key to continue . . . ");
            Console.ReadKey(true);
        }
    }

归并排序算法的时间复杂度是O（nlogn）,对于冒泡排序的O(n*n),效率还有有比较好的提高..

其实本人原来在学习的时候好长一段时间不理解为什么时间复杂度会是O（nlogn）,像冒泡排序就比较好理解，有两个for循环，问题的规模随着n变大而变大，算法时间复杂度自然就是O(n*n),后面花了一些时间来阅读一些资料才明白其原理，这里我已经将资料地址放到了本文最后，有兴趣的也可以去看看.简单的描述一下为什么会是O（nlogn）

大家看看，我们的例子，解一个8个元素的数组，我们用到了几层？是四层，假设我们这里有n个元素，我们会用到多少层？根据一定的归纳总结，我们知道我们会用到(lgn)+1层..(lgn)+1层需要用到lgn层次的合并算法.现在再看看MERGE (A, p, q, r )的复杂度是多少，毫无疑问O（n），故其归并排序的算法时间复杂度是O（nlogn）.当然这个结果还可以通过其他的方法计算出来，我这里是口语话最简洁的一种..

下面来一张算法时间复杂度的与n规模的关系图..

引用资料：http://www.personal.kent.edu/~rmuhamma/Algorithms/MyAlgorithms/Sorting/mergeSort.htm

算法系列目录：

1.算法系列总结：分治算法

2.算法系列总结：贪心算法

3.算法系列总结：动态规划(解公司外包成本问题）

4.算法系列总结：回溯算法（解火力网问题）

5.算法系列总结：分支限界算法

本文链接