在以前的博文别说不可能，nodejs中实现sleep中，我向大家介绍了nodejs addon的用法。今天的主题还是addon，继续挖掘c/c++的能力，弥补nodejs的弱点。
我曾多次提到过nodejs的性能问题。其实就语言本身而言，nodejs的性能还是很高的，虽然不及大多部静态语言，但差距也并不大；相对其他动态语言而言，速度优势非常明显。但为什么我们常常说nodejs不能胜任CPU密集型场景呢？因为由于其单线程特性，对于CPU密集型场景，它并不能充分利用CPU。计算机科学中有一个著名的Amdahl定律：
假设总工作量W，可以分解为两个部分：只能串行计算的Ws和允许并行计算的Wp。那么，在p个CPU并行计算的情况下，性能上能够带来speedup倍的提升。Amdahl定律描述了并行能做到的和不能做到的。它是一种理想情况，实际情况会复杂得多。比如并发很可能会引起资源的争夺，需要增加各种锁，从而常常让并行处于等待状态；并发还会额外带来操作系统对线程调度切换的时间开销，增加Ws。不过，当一项任务中，Wp比Ws大得多，并且有多个CPU核心可供使用时，并行带来的性能提升是相当可观的。
好，回到nodejs上。我们设想一个计算场景：计算4000000内的质数数目。这个场景编程实现的时候，以除法运算为主，不涉及内存、对象等操作，理论上能够确保让nodejs以相对较快的速度运行，不会落后c太多，便于对比。
javascript寻找质数的方法已经在这篇博客中提供了，直接抄过来：
复制代码 代码如下:
function zhishu_js(num) {
if (num == 1) {
return false;
}
if (num == 2) {
return true;
}
for (var i = 2; i <= Math.sqrt(num); i++) {
if (num % i == 0) {
return false;
}
}
return true;
}
再写一个c语言版本的：
复制代码 代码如下:
#include <math.h>
bool zhishu(int num){
if (num == 1) {
return false;
}
if (num == 2) {
return true;
}
for (int i = 2; i <= sqrt(num); i++) {
if (num % i == 0) {
return false;
}
}
return true;
};
在nodejs中，我们用一个从1到4000000的循环来检索质数；c语言中，我们设置若干个线程，定义count为4000000，每个线程做如下操作要：如果count大于0，则取出count的值，并计算是否为质数，同时将count减1。根据这个思路，javascript版本的很容易写：
复制代码 代码如下:
var count = 0;
for (j = 1; j < 4000000; j++) {
if(zhishu(j)){
count++;
}
}
关键难点就是c语言的多线程编程。早期c/c++并没有考虑并行计算的需求，所以标准库中并没有提供多线程支持。而不同的操作系统通常实现也是有区别的。为了避免这种麻烦，我们采用pthread来处理线程。
下载pthread最新版本。由于我对gyp不熟，link依赖lib搞了半天没搞定，最后我的方式是，直接把pthread的源代码放到了项目目录下，并在binding.gyp中把pthread.c添加到源代码列表中，在编译项目的时候把pthread也编译一次。修改后的binding.gyp是这样的：
复制代码 代码如下:
{
"targets": [
{
"target_name": "hello",
"sources": [ "hello.cc","pthreads/pthread.c" ],
"include_dirs": [
"<!(node -e \"require('nan')\")",
"pthreads"
],
"libraries": ["Ws2_32.lib"]
}
]
}
当然了，我这种方法很麻烦，如果你们只添加pthread中lib和include目录的引用，并且不出现依赖问题，那是最好的，就没有必要用我的方法来做。
那么接下来就进入C/C++多线程的一切了，定义一个线程处理函数：
复制代码 代码如下:
pthread_mutex_t lock;