1.概述
　　许多初学者对C/C++语言中的void及void指针类型不甚理解，因此在使用上出现了一些错误。本文将对void关键字的深刻含义进行解说，并

详述void及void指针类型的使用方法与技巧。

2.void的含义
　　void的字面意思是“无类型”，void *则为“无类型指针”，void *可以指向任何类型的数据。

　　void几乎只有“注释”和限制程序的作用，因为从来没有人会定义一个void变量，让我们试着来定义：

void a;

　　这行语句编译时会出错，提示“illegal use of type 'void'”。不过，即使void a的编译不会出错，它也没有任何实际意义。

　　void真正发挥的作用在于：
　　（1） 对函数返回的限定；
　　（2） 对函数参数的限定。

　　我们将在第三节对以上二点进行具体说明。

　　众所周知，如果指针p1和p2的类型相同，那么我们可以直接在p1和p2间互相赋值；如果p1和p2指向不同的数据类型，则必须使用强制类型

转换运算符把赋值运算符右边的指针类型转换为左边指针的类型。

　　例如：
float *p1;
int *p2;
p1 = p2;

　　其中p1 = p2语句会编译出错，提示“'=' : cannot convert from 'int *' to 'float *'”，必须改为：
p1 = (float *)p2;
而void *则不同，任何类型的指针都可以直接赋值给它，无需进行强制类型转换：
void *p1;
int *p2;
p1 = p2;

　　但这并不意味着，void *也可以无需强制类型转换地赋给其它类型的指针。因为“无类型”可以包容“有类型”，而“有类型”则不能包

容“无类型”。道理很简单，我们可以说“男人和女人都是人”，但不能说“人是男人”或者“人是女人”。下面的语句编译出错：
void *p1;
int *p2;
p2 = p1;

　　提示“'=' : cannot convert from 'void *' to 'int *'”。

3.void的使用

　　下面给出void关键字的使用规则：
　　规则一 如果函数没有返回值，那么应声明为void类型

　　在C语言中，凡不加返回值类型限定的函数，就会被编译器作为返回整型值处理。但是许多程序员却误以为其为void类型。例如：
add ( int a, int b )
{
return a + b;
}
int main(int argc, char* argv[])
{
printf ( "2 + 3 = %d", add ( 2, 3) );
}

　　程序运行的结果为输出：
　　2 + 3 = 5
　　这说明不加返回值说明的函数的确为int函数。

　　林锐博士《高质量C/C++编程》中提到：“C++语言有很严格的类型安全检查，不允许上述情况（指函数不加类型声明）发生”。可是编译

器并不一定这么认定，譬如在Visual C++6.0中上述add函数的编译无错也无警告且运行正确，所以不能寄希望于编译器会做严格的类型检查。

　　因此，为了避免混乱，我们在编写C/C++程序时，对于任何函数都必须一个不漏地指定其类型。如果函数没有返回值，一定要声明为void类

型。这既是程序良好可读性的需要，也是编程规范性的要求。另外，加上void类型声明后，也可以发挥代码的“自注释”作用。代码的“自注

释”即代码能自己注释自己。

     规则二 如果函数无参数,那么应声明其参数为void

　　在C++语言中声明一个这样的函数：
int function(void)
{
return 1;
}

　　则进行下面的调用是不合法的：
function(2);

　　因为在C++中，函数参数为void的意思是这个函数不接受任何参数。

　　我们在Turbo C 2.0中编译：
#include "stdio.h"
fun()
{
return 1;
}
main()
{
printf("%d",fun(2));
getchar();
}

　　编译正确且输出1，这说明，在C语言中，可以给无参数的函数传送任意类型的参数，但是在C++编译器中编译同样的代码则会出错。在C++

中，不能向无参数的函数传送任何参数，出错提示“'fun' : function does not take 1 parameters”。

　　所以，无论在C还是C++中，若函数不接受任何参数，一定要指明参数为void。至少我很少这样用。。

　　规则三 小心使用void指针类型

　　按照ANSI(American National Standards Institute)标准，不能对void指针进行算法操作，即下列操作都是不合法的：
void * pvoid;
pvoid++; //ANSI：错误
pvoid += 1; //ANSI：错误
//ANSI标准之所以这样认定，是因为它坚持：进行算法操作的指针必须是确定知道其指向数据类型大小的。
//例如：
int *pint;
pint++; //ANSI：正确

　　pint++的结果是使其增大sizeof(int)。

　　但是大名鼎鼎的GNU(GNU's Not Unix的缩写)则不这么认定，它指定void *的算法操作与char *一致。

　因此下列语句在GNU编译器中皆正确：
pvoid++; //GNU：正确
pvoid += 1; //GNU：正确

　　pvoid++的执行结果是其增大了1。

　　在实际的程序设计中，为迎合ANSI标准，并提高程序的可移植性，我们可以这样编写实现同样功能的代码：
void * pvoid;
(char *)pvoid++; //ANSI：正确；GNU：正确
(char *)pvoid += 1; //ANSI：错误；GNU：正确

　　GNU和ANSI还有一些区别，总体而言，GNU较ANSI更“开放”，提供了对更多语法的支持。但是我们在真实设计时，还是应该尽可能地迎合

ANSI标准。

　　规则四 如果函数的参数可以是任意类型指针，那么应声明其参数为void *

　　典型的如内存操作函数memcpy和memset的函数原型分别为：
void * memcpy(void *dest, const void *src, size_t len);
void * memset ( void * buffer, int c, size_t num );

　　这样，任何类型的指针都可以传入memcpy和memset中，这也真实地体现了内存操作函数的意义，因为它操作的对象仅仅是一片内存，而不

论这片内存是什么类型。如果memcpy和memset的参数类型不是void *，而是char *，那才叫真的奇怪了！这样的memcpy和memset明显不是一个

“纯粹的，脱离低级趣味的”函数！

下面的代码执行正确：
//示例：memset接受任意类型指针
int intarray[100];
memset ( intarray, 0, 100*sizeof(int) ); //将intarray清0

//示例：memcpy接受任意类型指针
int intarray1[100], intarray2[100];
memcpy ( intarray1, intarray2, 100*sizeof(int) ); //将intarray2拷贝给intarray1

　　有趣的是，memcpy和memset函数返回的也是void *类型，标准库函数的编写者是多么地富有学问啊！

　　规则五 void不能代表一个真实的变量

　　下面代码都企图让void代表一个真实的变量，因此都是错误的代码：
void a; //错误
function(void a); //错误

　　void体现了一种抽象，这个世界上的变量都是“有类型”的，譬如一个人不是男人就是女人（还有人妖？）。

　　void的出现只是为了一种抽象的需要，如果你正确地理解了面向对象中“抽象基类”的概念，也很容易理解void数据类型。正如不能给抽

象基类定义一个实例，我们也不能定义一个void（让我们类比的称void为“抽象数据类型”）变量。

4.总结
　　小小的void蕴藏着很丰富的设计哲学，作为一名程序设计人员，对问题进行深一个层次的思考必然使我们受益匪浅。

假设有共享的资源sum,与之相关联的mutex 是lock_s.假设每个线程对sum的操作很简单的,与sum的状态无关,比如只是sum++.那么只用mutex足够了.程序员只要确保每个线程操作前,取得lock,然后sum++,再unlock即可.每个线程的代码将像这样add()
{
　　pthread_mutex_lock(lock_s);
　　sum++;
　　pthread_mutex_unlock(lock_s);
}

　　如果操作比较复杂,假设线程t0,t1,t2的操作是sum++,而线程t3则是在sum到达100的时候,打印出一条信息,并对sum清零.这种情况下,如果只用mutex, 则t3需要一个循环,每个循环里先取得lock_s,然后检查sum的状态,如果sum>=100,则打印并清零,然后unlock.如果sum<100,则unlock,并sleep()本线程合适的一段时间.

　这个时候,t0,t1,t2的代码不变,t3的代码如下
　　print()
　　{
　　　　while (1)
　　　　{
　　　　　　pthread_mutex_lock(lock_s);
　　　　　　if(sum<100)
　　　　　　{
　　　　　　　　printf(“sum reach 100!”);
　　　　　　　　pthread_mutex_unlock(lock_s);
　　　　　　}
　　　　　　else
　　　　　　{
　　　　　　　　pthread_mutex_unlock(lock_s);
　　　　　　　　my_thread_sleep(100);
　　　　　　　　return OK;
　　　　　　}
　　　　}
　　}

这种办法有两个问题
　　1) sum在大多数情况下不会到达100,那么对t3的代码来说,大多数情况下,走的是else分支,只是lock和unlock,然后sleep().这浪费了CPU处理时间.
　　2) 为了节省CPU处理时间,t3会在探测到sum没到达100的时候sleep()一段时间.这样却又带来另外一个问题,亦即t3响应速度下降.可能在sum到达200的时候,t3才会醒过来.
　　3) 这样,程序员在设置sleep()时间的时候陷入两难境地,设置得太短了节省不了资源,太长了又降低响应速度.真是难办啊!

　　这个时候,condition variable内裤外穿,从天而降,拯救了焦头烂额的你.

　　你首先定义一个condition variable.
　　pthread_cond_t cond_sum_ready=PTHREAD_COND_INITIALIZER;

　　t0,t1,t2的代码只要后面加两行,像这样
　　add()
　　{
　　　　pthread_mutex_lock(lock_s);
　　　　sum++;
　　　　pthread_mutex_unlock(lock_s);
　　　　if(sum>=100)
　　　　pthread_cond_signal(&cond_sum_ready);
　　}
　　而t3的代码则是
　　print
　　{
　　　　pthread_mutex_lock(lock_s);
　　　　while(sum<100)
　　　　pthread_cond_wait(&cond_sum_ready, &lock_s);
　　　　printf(“sum is over 100!”);
　　　　sum=0;
　　　　pthread_mutex_unlock(lock_s);
　　　　return OK;
　　}

注意两点:
　　1) 在thread_cond_wait()之前,必须先lock相关联的mutex, 因为假如目标条件未满足,pthread_cond_wait()实际上会unlock该mutex, 然后block,在目标条件满足后再重新lock该mutex, 然后返回.

　　2) 为什么是while(sum<100),而不是if(sum<100) ?这是因为在pthread_cond_signal()和pthread_cond_wait()返回之间,有时间差,假设在这个时间差内,还有另外一个线程t4又把sum减少到100以下了,那么t3在pthread_cond_wait()返回之后,显然应该再检查一遍sum的大小.这就是用while的用意

boost lib

http://www.stlchina.org/twiki/bin/view.pl/Main/BoostThread#safag7ZYn7rqw

文章出处：DIY部落(http://www.diybl.com/course/3_program/c++/cppxl/20090508/166837.html)

基本操作

#include <semaphore.h>
int sem_init(sem_t *sem, int pshared, unsigned int value);
int sem_wait(sem_t *sem);          /**//* P(sem), wait(sem) */
int sem_post(sem_t *sem);          /**//* V(sem), signal(sem) */

int sem_getvalue(sem_t *sem, int *sval);
int sem_trywait(sem_t *sem);

int sem_destroy(sem_t *sem);       /**//* undo sem_init() */

/**//* named semaphores - these are less useful here */
sem_t *sem_open(  );
int sem_close(sem_t *sem);
int sem_unlink(const char *name);

互斥量

基本操作

#include <pthread.h>
int pthread_mutex_init(pthread_mutex_t *mutex, pthread_mutexattr_t *attr);
pthread_mutex_t mutex = PTHREAD_MUTEX_INITIALIZER;
int pthread_mutex_lock(pthread_mutex_t *mutex);
int pthread_mutex_unlock(pthread_mutex_t *mutex);

int pthread_mutex_trylock(pthread_mutex_t *mutex);
int pthread_mutex_destroy(pthread_mutex_t *mutex); 

条件变量

一种信号机制

基本操作

#include <pthread.h>
int pthread_cond_init(pthread_cond_t *cond, pthread_condattr_t *attr);
pthread_cond_t cond = PTHREAD_COND_INITIALIZER;
int pthread_cond_wait(pthread_cond_t *cond, pthread_mutex_t *mutex);
int pthread_cond_signal(pthread_cond_t *cond);

int pthread_cond_timedwait(  );
int pthread_cond_broadcast(pthread_cond_t *cond);
int pthread_cond_destroy(pthread_cond_t *cond); 

互斥量A保护条件变量B

//等待方
pthread_mutex_lock(&A);
while(){//检查条件是否满足
    pthread_cond_wait(&B, &A);
}
  /**//* wait会隐式解锁A */
  /**//* wait后A会被隐式锁住A */
pthread_mutex_unlock(&A);

//通知方
pthread_mutex_lock(&A);
pthread_cond_signal(&B);
pthread_mutex_unlock(&A);

我的问题来了，假如是一个进程使用了udp的阻塞recvfrom()方法，在网络连接没有数据到达时，进程会在这个方法上面阻塞？这个阻塞的意思是进程会进入等待队列，此时的进程处于下列的什么状态？？然后cpu进而调度其他进程。。。还是cpu仍然给此进程分配时间片在它自己的时间片上让其阻塞在此方法上,这不是浪费cpu时间??
我是真的得好好看看操作系统的书了

D Uninterruptible sleep (usually IO)
不可中断的深度睡眠，一般由IO引起，同步IO在做读或写操作时，此进程不能做其它事情，只能等待，这时进程处于这种状态，如果程序采用异步IO，这种状态应该就很少见到了
 
R Running or runnable (on run queue) 
进程处于运行或就绪状态
 
S Interruptible sleep (waiting for an event to complete)
可接收信号的睡眠状态，sleep函数可演示这种状态
 
T Stopped, either by a job control signal or because it is being traced.
被ctrl+z中断或被trace
 
W paging (not valid since the 2.6.xx kernel)
 
X dead (should never be seen)
进程已经完全死掉，不可能看见这种状态的
 
Z Defunct ("zombie") process, terminated but not reaped by its parent.
进程已经终止，但是其父进程没有来及处理它，多进程写不好的话，这种状态是常见的
 
For BSD formats and when the stat keyword is used, additional characters may
be displayed:
< high-priority (not nice to other users)
 
N low-priority (nice to other users)
 
L has pages locked into memory (for real-time and custom IO)
 
s is a session leader
 
l is multi-threaded (using CLONE_THREAD, like NPTL pthreads do)
 
+ is in the foreground process group
 
关于D和Z一段有趣的解释：
 
    有一类垃圾却并非这么容易打扫，那就是我们常见的状态为 D (Uninterruptible sleep) ，以及状态为 Z (Zombie) 的垃圾进程。这些垃圾进程要么是求而不得，像怨妇一般等待资源(D)，要么是僵而不死，像冤魂一样等待超度(Z)，它们在 CPU run_queue 里滞留不去，把 Load Average 弄的老高老高，没看过我前一篇blog的国际友人还以为这儿民怨沸腾又出了什么大事呢。怎么办？开枪！kill -9！看你们走是不走。但这两种垃圾进程偏偏是刀枪不入的，不管换哪种枪法都杀不掉它们。无奈，只好reboot，像剿灭禽流感那样不分青红皂白地一律扑杀！
 
    怨妇 D，往往是由于 I/O 资源得不到满足，而引发等待，在内核源码 fs/proc/array.c 里，其文字定义为“ "D (disk sleep)", /* 2 */ ”（由此可知 D 原是Disk的打头字母），对应着 include/linux/sched.h 里的“ #define TASK_UNINTERRUPTIBLE 2 ”。举个例子，当 NFS 服务端关闭之时，若未事先 umount 相关目录，在 NFS 客户端执行 df 就会挂住整个登录会话，按 Ctrl+C 、Ctrl+Z 都无济于事。断开连接再登录，执行 ps axf 则看到刚才的 df 进程状态位已变成了 D ，kill -9 无法杀灭。正确的处理方式，是马上恢复 NFS 服务端，再度提供服务，刚才挂起的 df 进程发现了其苦苦等待的资源，便完成任务，自动消亡。若 NFS 服务端无法恢复服务，在 reboot 之前也应将 /etc/mtab 里的相关 NFS mount 项删除，以免 reboot 过程例行调用 netfs stop 时再次发生等待资源，导致系统重启过程挂起。

　　冤魂 Z 之所以杀不死，是因为它已经死了，否则怎么叫 Zombie（僵尸）呢？冤魂不散，自然是生前有结未解之故。在UNIX/Linux中，每个进程都有一个父进程，进程号叫PID（Process ID），相应地，父进程号就叫PPID（Parent PID）。当进程死亡时，它会自动关闭已打开的文件，舍弃已占用的内存、交换空间等等系统资源，然后向其父进程返回一个退出状态值，报告死讯。如果程序有 bug，就会在这最后一步出问题。儿子说我死了，老子却没听见，没有及时收棺入殓，儿子便成了僵尸。在UNIX/Linux中消灭僵尸的手段比较残忍，执行 ps axjf 找出僵尸进程的父进程号（PPID，第一列），先杀其父，然后再由进程天子 init（其PID为1，PPID为0）来一起收拾父子僵尸，超度亡魂，往生极乐。注意，子进程变成僵尸只是碍眼而已，并不碍事，如果僵尸的父进程当前有要务在身，则千万不可贸然杀之。