_1_0.txt)
8 //
9 // See http://www.boost.org for updates, documentation, and revision history.
10
11 #ifndef ALLOCATOR_GUARD_HPP_
12 #define ALLOCATOR_GUARD_HPP_
13
14
15 template
16 class guard
17 {
18 private:
19 Mutex& mtx;
20 guard(const guard&);
21 void operator =(const guard&);
22 public:
23 explicit guard(Mutex& nmtx) : mtx(nmtx) { mtx.lock(); }
24 ~guard() { mtx.unlock(); }
25 };
26
27 #endif
理论上一般情况下上述内存管理器比较节约内存，因为每块内存的开销仅仅1字节，64个这样的小块组成一个chunk，仅再需要8字节开销，远远比一般的new/malloc节约内存。当然，有人可能争辩说这1字节的开销也可以去掉，用自由列表就是了，而问题恰恰出在这里。用自有列表可以避免搜索位图，分配和回收内存均在一个内存池里进行，速度更快，但是对于长生命周期的对象来说，跟泄漏内存没有什么分别。还是用上面的那个双链表为例，用自由列表理论上1M个节点仅需要12MB堆内存，但是如果该链表哪怕只有1个节点，从操作系统看上去也会用12MB堆内存，而此时我们的单对象位图内存管理器需要840(8 + 64 * (12+1) = 840)字节堆内存，从操作系统看上去是1页(多数32位系统是4096字节)。
需要指出的是single_object_allocator跟STL的allocator分配和回收内存的行为完全不同，不能用它来当作std::list的第二个参数，否则需要修改allocate/deallocate的实现代码。
single_object_allocator只能管理等大的内存块，此时可能比一般比系统的malloc/free, new/delete速度稍快一些，尽管它的设计初衷是为了尽可能的节约内存。
|