PF2.1版本总结，在设计过程中遇到的问题以及技术分享

[blockquote]

在距离上一次的版本发布已经过去4个月的时间，因为个人的能力以及时间有限，所以这次的版本会推迟这么久。可是无论怎样，PF2.1带着自身的完善总算不负所望推出。在这次的版本调整中让我深有体会到了程序设计中的几大问题：安全、性能、稳定。如何设计出一个高效稳定的框架时，自然需要对所运用的语言的熟知，在这期间我一直参考了《effective c++》这本对C++语言总结的十分详细的资料，结合了最新C++11的新特性。

[/blockquote]

版本更新

1、增加：cache模块

2、增加：lua插件中的dcache模块

3、增加：对应的windows专用版本仓库

4、优化：利用C++11新特性修改basic的type::variable_t的实现机制

5、优化：动态分配内存类修改、替换数据库查询中的结果缓存数据为堆的实现方式（之前栈的方式会导致windows栈溢出）

6、修复：share::Map、share::lock/unlock、db::Query在多线程不能正常工作的问题

在这次的版本中遇到的最多问题是多线程下以及windows平台上兼容的问题，深刻体会到VC的实现与GNU的区别。虽然平台之间存在兼容性，可是一些硬性的C++标准是不会有什么区别的。对于存在的问题，该版本进行了大刀阔斧的修正，绝对没有存在任何侥幸和姑息。我将从以下几个方面来分享：共享锁、泛型编程、线程池。

共享锁

　　共享锁的实现目的是为了在同时访问这些公用的内存时数据的正确性，这与多线程中的锁是类似的。不过共享锁的实现是以std::atomic的CAS（compare_exchange_weak）方式实现的，这方面可以查询一下相关的资料，当然这是在C++11标准中的，旧的标准没有。

在pf_cache::DbStore以及核心的share::Map中我都用到了共享锁，当前这个共享锁的实现可能并不完美，不过在测试下可以进行正常的工作。

std::atomic的数据是在共享内存中存在的，因此在我们队单个对象节点（node）进行操作时需要保证它是被正确修改的，即锁的本身需要保证安全和可靠。同时最重要一点的是我们再进行一个整体操作时，比如share::Map中删除一个数据需要涉及到内部内存的变动，那么这整个改变应该是唯一的，因此在这过程中我们需要全程加锁，避免另一个删除操作（多线程）修改我们这些数据，导致操作内存的混乱错误。

泛型编程

　　什么是泛型编程？

我们要理解它的含义，那么我们可以看一个类型，那就是void *，它表示什么意思呢？我们可以称它为空指针，同时它还有另一个名字：泛型指针。

为什么void *被叫做泛型指针呢？想想我们用它的场景，应该不难发现，它的最大作用时表示任何的指针，它可以很轻松的转换为你想要的类型，因此它本身是与类型没有任何关系的。

泛型编程和void *指针一样，它本身是和类型无关的，原则上是通用的。而在C++中的实现方式，是以类（结构体）和函数模板（template）的方式。

本次版本中就使用了模板的方式重构了type::variable_struct，从原来约1500行代码缩短到约600行，这可见泛型编程的优越。

不过在模板中我觉得需要注意的是模板特化的实现方式，这一点可以查找相关资料即可。

线程池

　　提到池的概念，有许多人可能会想到内存池，这是因为我们在学习过程中许多书籍上都会有相关的介绍。线程池的概念却有些区别，虽然它也是一个相当于存储许多线程的容器，不过我认为它更像一个工作小组。

我们之所以要用到多线程和线程池的原因，就是为了充分利用机器的线程优势，就好比原来只有一个人做的工作，现在分摊到许多人的身上，自然这样的工作效率是成倍的提升的。而PF现在的线程池在类pf_sys::ThreadPool中，是一位开源贡献者实现的。它利用了C++的新特性，在线程池构造时便创建了许多的工作线程，并让它们进入休眠中，当有一个新的任务时，它会利用线程条件通知的方式唤醒线程进行工作。

在pf_cache::DbStore中的waitquery便使用了线程池，有兴趣的可以去查看，自然也欢迎大家能指正错误。

附录

　　github for linux:  https://github.com/viticm/plainframework

github for windows: https://github.com/viticm/pf_win

讨论QQ群： 348477824