总结在前
1语言特性的差异
1.1字节顺序的差异Windows低位在前 Unix高位在前
差异带来的问题，体现在以下几个方面：Ø 网络通信时Ø 网络通信时
解决方法：1． 数字转换成字符传进行交互 2． 协商一个统一的字节顺序，根据自己平台的字节顺序还原数据 3． 采用其他标准的编码方式，如ASN1编码备注：32位系统和64位系统的差异也会出现这样的问题，长整型（long）分 别用32位和64位表示，这样，在不同系统之间交互的时候必然会出现 整型数据表示方式不同的问题。目前大多数Windows系统都是32位的系统，而 Unix中很多都是64位的。1.2变量的作用域差异
1.3全局对象的初始化
CMyObject g_Object; windows环境，默认调用构造函数，但是在某些系统中（SCO Unix）不调用，可以通过显式创建对象的方法解决，如下： CMyObject* g_pObject = new CMyObject; 如果不想使用指针的方式引用该对象，我们可以用如下方法： CMyObject& g_Object = *(new CMyObject); 1.4 语法检查的差异 if(NULL == pVar) 在SCO Unix环境下报错
2 操作系统特性的差异: 打开文件句柄数的限制、Socket等待队列的限制、进程和线程堆栈大小的限制等
2.1 文件描述符的限制: 文件描述符最初是Unix下的一个概念以Solaris为例，默认情况下每个进程可以打开的文件描述符为 1024个，系统的硬限制是8192（具体的值跟版本有关）。在Unix系统下使用ulimit命令来获得系统的这些限制参 数。一般情况下，这都是够用的，但是有一个例外，在32为的Solaris程序中，使用标准输入输出函数（stdio）进行文件的操作，最大的文件描述符不能超过256。比如说用fopen打开文件，除去系统占用的3个文件描述符（stdin、stdout和stderr），程序中只能再同时打开253个 文件。如果使用open函数来打开文件，就没有这个限制，但是就不能够使用stdio中的那些函数进行操作了，是程序的通用性和灵活性有所降低。这是因为 在stdio的FILE结构中，用一个unsigned char来表示文件描述符，所以只能表示0～255。 在网络程序的开发中，每一个网络连接也都占用一个文件描述符，如果程序打开了很多Socket连接（典型的例子就是使用了连接池技术），那么程序运行的时候可能用fopen打不开文件。 解决这个问题，可以采用一下几种方法： 1． 升级为64位系统或采用采用64位方式编译程序 2． 使用sys/io.h中的函数操作文件 3． 采用文件池技术，预留一部分文件描述符（3～255之间的），使用freopen函数来重用这些描述符。 至于采用哪种方法或者是否考虑系统中处理这个问题，就要视具体的情况而定了，那些不受这个限制影响的程序，可以不考虑这个问题。 1.2.2 进程和线程的限制一般的操作系统对每个进程和线程可以使用的资源数都有限制，比如一个进程可以创建的线程数，一个进程可以打开的文件描述符的数量，进程和线程栈大小的限制和默认值等。 针对这些问题，首先要分析和考虑你的系统是一个什么样的规模，会不会收到这些限制的影响，如果需求大于系统的限制，可以通过适当的调整系统参数来解决，如果还不能解决，就得考虑采用多进程的方式来解决。 对于进程和线程的栈空间大小的限制，主要是线程栈空间的问题。一般的系统都有默认的线程栈空间大小，而且不同操作系统的默认值可能不同。在通常情况下，这些对程序没有影响，但是当程序的层次结构比较复杂，使用了过多的本地变量，这个限制可能就会对程序产生影响，导致栈空间溢出，这是一个比较严重的问题。不能通过调整系统参数来解决这个问题，但是可以通过相应的函数，在程序里面指定创建线程的栈空间的大小。但是具体该调整的数值应该适可而止，而不是越大越好。 因为线程的栈空间过大的时候，就会影响到可创建线程的数量，虽然远没有达到系统多线程数的限制，但却可能因为系统资源占用过多导致分配内存失败。
文件描述符最初是Unix下的一个概念1.2 操作系统特性的差异不同的操作系统中都存在一些系统的限制，如打开文件句柄数的限制、Socket等待队列的限制、进程和线程堆栈大小的限制等，因此在开发的过程中，必须考虑 到这些限制因素对程序的影响。当然，有些限制参数可以适当的调整，这就需要在发布程序的时候加以声明。另外，操作系统的容错性也对程序有影响。下面分别进 行讨论。 1.2.1 文件描述符的限制文件描述符最初是Unix下的一个概念，在Unix系统中，用文件描述符来表示文件、打开的socket连接等，跟Windows下HANDLE的概念类 似。文件描述符是一种系统资源，系统对每个进程可以分配的文件描述符数量都有限制。以Solaris为例，默认情况下每个进程可以打开的文件描述符为 1024个，系统的硬限制是8192（具体的值跟版本有关），也就是说可以调整到8192。在Unix系统下使用ulimit命令来获得系统的这些限制参 数。一般情况下，这都是够用的，但是有一个例外，在32为的Solaris程序中，使用标准输入输出函数（stdio）进行文件的操作，最大的文件描述符不能超过256。比如说用fopen打开文件，除去系统占用的3个文件描述符（stdin、stdout和stderr），程序中只能再同时打开253个 文件。如果使用open函数来打开文件，就没有这个限制，但是就不能够使用stdio中的那些函数进行操作了，是程序的通用性和灵活性有所降低。这是因为 在stdio的FILE结构中，用一个unsigned char来表示文件描述符，所以只能表示0～255。 在网络程序的开发中，每一个网络连接也都占用一个文件描述符，如果程序打开了很多Socket连接（典型的例子就是使用了连接池技术），那么程序运行的时候可能用fopen打不开文件。 解决这个问题，可以采用一下几种方法： 1． 升级为64位系统或采用采用64位方式编译程序 2． 使用sys/io.h中的函数操作文件 3． 采用文件池技术，预留一部分文件描述符（3～255之间的），使用freopen函数来重用这些描述符。 至于采用哪种方法或者是否考虑系统中处理这个问题，就要视具体的情况而定了，那些不受这个限制影响的程序，可以不考虑这个问题。 1.2.2 进程和线程的限制一般的操作系统对每个进程和线程可以使用的资源数都有限制，比如一个进程可以创建的线程数，一个进程可以打开的文件描述符的数量，进程和线程栈大小的限制和默认值等。 针对这些问题，首先要分析和考虑你的系统是一个什么样的规模，会不会收到这些限制的影响，如果需求大于系统的限制，可以通过适当的调整系统参数来解决，如果还不能解决，就得考虑采用多进程的方式来解决。 对于进程和线程的栈空间大小的限制，主要是线程栈空间的问题。一般的系统都有默认的线程栈空间大小，而且不同操作系统的默认值可能不同。在通常情况下，这些对程序没有影响，但是当程序的层次结构比较复杂，使用了过多的本地变量，这个限制可能就会对程序产生影响，导致栈空间溢出，这是一个比较严重的问题。不能通过调整系统参数来解决这个问题，但是可以通过相应的函数，在程序里面指定创建线程的栈空间的大小。但是具体该调整的数值应该适可而止，而不是越大越好。 因为线程的栈空间过大的时候，就会影响到可创建线程的数量，虽然远没有达到系统多线程数的限制，但却可能因为系统资源占用过多导致分配内存失败。
文件描述符最初是Unix下的一个概念，以Solaris为例，默认情况下每个进程可以打开的文件描述符为 1024个，系统的硬限制是8192（具体的值跟版本有关），也就是说可以调整到8192。在Unix系统下使用ulimit命令来获得系统的这些限制参 数。一般情况下，这都是够用的，但是有一个例外，在32为的Solaris程序中，使用标准输入输出函数（stdio）进行文件的操作，最大的文件描述符不能超过256。比如说用fopen打开文件，除去系统占用的3个文件描述符（stdin、stdout和stderr），程序中只能再同时打开253个 文件。如果使用open函数来打开文件，就没有这个限制，但是就不能够使用stdio中的那些函数进行操作了，是程序的通用性和灵活性有所降低。这是因为 在stdio的FILE结构中，用一个unsigned char来表示文件描述符，所以只能表示0～255。 在网络程序的开发中，每一个网络连接也都占用一个文件描述符，如果程序打开了很多Socket连接（典型的例子就是使用了连接池技术），那么程序运行的时候可能用fopen打不开文件。 解决这个问题，可以采用一下几种方法： 1． 升级为64位系统或采用采用64位方式编译程序 2． 使用sys/io.h中的函数操作文件 3． 采用文件池技术，预留一部分文件描述符（3～255之间的），使用freopen函数来重用这些描述符。 至于采用哪种方法或者是否考虑系统中处理这个问题，就要视具体的情况而定了，那些不受这个限制影响的程序，可以不考虑这个问题。 2.2 进程和线程的限制一般的操作系统对每个进程和线程可以使用的资源数都有限制，比如一个进程可以创建的线程数，一个进程可以打开的文件描述符的数量，进程和线程栈大小的限制和默认值等。 针对这些问题，首先要分析和考虑你的系统是一个什么样的规模，会不会收到这些限制的影响，如果需求大于系统的限制，可以通过适当的调整系统参数来解决，如果还不能解决，就得考虑采用多进程的方式来解决。 对于进程和线程的栈空间大小的限制，主要是线程栈空间的问题。一般的系统都有默认的线程栈空间大小，而且不同操作系统的默认值可能不同。在通常情况下，这些对程序没有影响，但是当程序的层次结构比较复杂，使用了过多的本地变量，这个限制可能就会对程序产生影响，导致栈空间溢出，这是一个比较严重的问题。不能通过调整系统参数来解决这个问题，但是可以通过相应的函数，在程序里面指定创建线程的栈空间的大小。但是具体该调整的数值应该适可而止，而不是越大越好。 因为线程的栈空间过大的时候，就会影响到可创建线程的数量，虽然远没有达到系统多线程数的限制，但却可能因为系统资源占用过多导致分配内存失败。
1. 平台差异简介
Windows 和Unix是当前两大主流操作系统平台，基于C/C++的开发人员经常会面临这两个平台之间的移植的问题。Unix作为一个开发式的系统，其下有出现了很 多个分支，包括Sun的Solaris、IBM的AIX、HP Unix、SCO Unix、Free BSD、苹果的MAC OS以及开源的Linux等。对于这些Unix的分支操作系统，其实现又有很大的差别，因此开发人员又要针对这些不同的系统进行移植。本文的目的就是介绍 一下Windows平台和Unix平台之间的差别，并简单介绍一下不同Unix分支操作系统之间的差别，在移植开发过程中的一些注意事项，同时简要介绍一 下Unix下开发的一般流程和常用的开发调试工具。
关于平台之间的差异，主要是Windows平台和Unix平台之间的差异，这里着重介绍一下这两个平台在C/C++开发中存在的差异，其间会穿插介绍一些Unix不同分支之间的差异。
1.1语言特性的差异
语言特性的差异，指的是不同操作系统平台中，实现C++/C时的一些细微的差异，忽略这些差异可能会带来一些特别隐蔽的错误。而且可能是致命的错误。所 以，了解语言特性的差异，对于在Unix移植来说非常重要。如果考虑系统多多个平台支持，就必须了解在不同平台下语言特性的差异，从开发一开始就把这些因 素考虑进去，这样才能最低限度的降低移植的过程中工作量。
1.1.1字节顺序的差异
字节顺序指的主要是整型变量在内存中的存储方式。在计算机中，数据都是以二进制方式存储的，包括在内存和硬盘中。而计算机又以8位二进制作为一个存储单元。在32位系统中，一个整型的存储需要四个存储单元。也就是说要把一个32位的整数分割成位四段分别进行存储，而每一个存储单元的位置就是字节顺序的差异。 为了清楚的表示每段存储的先后位置，我们用16进制来表示一段的值，下表列出了在Unix系统和Windows系统中整数20000在内存中的情况。
十六进制表示 Windows内存表示Unix内存表示
0x00004E20 20 4E 00 0000 00 4E 20
如表中所示，Windows中存储方式和该整数的16进制表示是相反，是一种低位在前高位在后的存储顺序。而Unix下的存储顺序和正常的16进制表示的顺序相同，称为高位在前低位在后的顺序。这种差异带来的问题，主要体现在以下几个方面：
Ø 网络通信时
当Windows 和Unix之间发生网络数据传输，传输一个整型数据（如一个数据包的长度）的时候，如果不经处理直接把内存中的数据传输过去，那么在对方看来完全是另一个 数据，这样就会造成问题。如Windows下面发送过去一个20000（0x00004E20），在Unix下面收到的数据就会被理解成 541982720（0x204E0000），这简直是天壤之别。
Ø 文件存储和读取时
跟网络传输类似，如果在Windows下面把某个整数写到了文件中，然后在Unix下面打开这个文件读取该数据，就会出现跟上面类似的问题。
这个问题主要体现在不同平台之间互操作时，解决这个问题的方法就是交互的双方采用一种相同的数据编码标准，就是数据在传输和存储的时候采用什么方法进行编码，具体的解决方法有一下几种：
1． 数字转换成字符传进行交互
2． 协商一个统一的字节顺序，根据自己平台的字节顺序还原数据
3． 采用其他标准的编码方式，如ASN1编码
跟这个问题类似，32位系统和64位系统的差异也会出现这样的问题，解决方法跟这个问题的解决方法相同。在32位系统和64位系统中，长整型（long）分 别用32位和64位表示，这样，在不同系统之间交互的时候必然会出现整型数据表示方式不同的问题。目前大多数Windows系统都是32位的系统，而 Unix中很多都是64位的，尤其是大型的服务器，所以这个问题必须引起重视。
1.1.2变量的作用域差异
在不同的系统下，由于编译器的不同，对变量作用域的实现机制也有所不同，这里以Windows下的VC和Solaris下的CC这两个编译器为例做一个简单的比较说明。
在C++的开发过程中，我们经常会有这样的用法：
for(int i=0;i<num;i++)
{ … }
这 是一种最常用的for循环的用法，因为其中i主要使用来控制循环，所以一般没有必要拿出来单独进行声明，只是放在for语句中一起声明。就是这种声明方法，在Windows下和Solaris下有了不同的理解，i 的作用域不 同。我们先把作用域进行划分，如下：
我 们划分出 I 和 II 两个作用域，其中作用域 II 包含在作用域 I 当中。在Windows下，变量 i 的作用域是I的整个范围，而Solaris下的i的作用域只 是II的范围。其实标准的C++语法应该是Solaris的做法，但是微软在实现的时候没有按照这个标准实现，这就引发了我们讨论的这个问题。由于这个差 异，就引发了一些微妙而隐蔽的问题。先看一下下面两端代码。
A： 标准的C++语法应该是Solaris的做法
for(int i=0;i<num;i++)
{ … }
for(i=0;i<num;i++)
{ … }
B： Windows下
for(int i=0;i<num;i++)
{ … }
for(int i=0;i<num;i++)
{ … }
1.1.3全局对象的初始化
在C++中，初始化对象的时候系统会自动调用构造函数，因此我们习惯在构造函数中做一些初始化的工作。其中，有些对象是静态分配的全局对象（就是在任何函数体外声明的对象），如：
CMyObject g_Object;
通常情况下，程序启动的时候，系统都会自动调用这个对象的构造函数对这个全局对象进行初始化，但是在某些系统中（SCO Unix），就不想我们期望的那样，也许这是编译器实现的一个bug，但是我们也不能忽视这个问题的存在。对于这种问题，我们可以通过显式创建对象的方法 解决，如下：
CMyObject* g_pObject = new CMyObject;
这样，系统在启动的时候，就会执行new CMyObject来为对象分配空间，同时执行调用对象的构造函数来初始化对象。如果不想使用指针的方式引用该对象（为了安全因素，不想某个函数在程序运行期间把这个指针置空），那么我们可以采用另一种方法，如下：
CMyObject& g_Object = *(new CMyObject);
这样也可以达到对像创建和初始化的工作。虽然对于我们分配的这个对象没有进行释放操作，但是全局只有这么一次，所以不用担心内存泄漏问题。程序运行结束的时候，操作系统会自动释放掉程序所申请的所有内存，当然也包含这个对象。
1.1.4 语法检查的差异
不同操作系统下面有不同的编译器的实现，不同的编译器对语法要求的程度不同。在Windows下可以正常编译的代码，在Unix下就可能出现语法错误。1.1.2中就是一个典型的例子。另外，还有一些其他方面的语法检查的差异。
C 是一种很灵活的语言，语法很*，但是不同的平台下这种*的程度也不同。Windows VC、Solaris CC和Linux gcc实现的都不错，但是有些其他的系统实现的就不是这么灵活，很多写法在他们下面都行不通。具体的记不太清了，在AIX和SCO Unix下面碰到很多这种情况。所以只能在移植的过程中逐渐的发现和改正。但是只要保证采用标准的书写规范，应该可以更少的产生这种错误。
有这样一段代码：
if(NULL == pVar)
{ … }
这是在大多数平台下面很好的一种习惯，可以避免哪种把“==”写成“=”的错误，在编译期间就能发现。但是在SCO Unix下面，这种写法就会引发编译器的一个警告。这个例子能简单的说明一下不同编译器之间存在的差别。
1.2 操作系统特性的差异
不同的操作系统中都存在一些系统的限制，如打开文件句柄数的限制、Socket等待队列的限制、进程和线程堆栈大小的限制等，因此在开发的过程中，必须考虑 到这些限制因素对程序的影响。当然，有些限制参数可以适当的调整，这就需要在发布程序的时候加以声明。另外，操作系统的容错性也对程序有影响。下面分别进 行讨论。
1.2.1 文件描述符的限制
文件描述符最初是Unix下的一个概念，在Unix系统中，用文件描述符来表示文件、打开的socket连接等，跟Windows下HANDLE的概念类 似。文件描述符是一种系统资源，系统对每个进程可以分配的文件描述符数量都有限制。以Solaris为例，默认情况下每个进程可以打开的文件描述符为 1024个，系统的硬限制是8192（具体的值跟版本有关），也就是说可以调整到8192。在Unix系统下使用ulimit命令来获得系统的这些限制参 数。一般情况下，这都是够用的，但是有一个例外，在32为的Solaris程序中，使用标准输入输出函数（stdio）进行文件的操作，最大的文件描述符不能超过256。比如说用fopen打开文件，除去系统占用的3个文件描述符（stdin、stdout和stderr），程序中只能再同时打开253个 文件。如果使用open函数来打开文件，就没有这个限制，但是就不能够使用stdio中的那些函数进行操作了，是程序的通用性和灵活性有所降低。这是因为 在stdio的FILE结构中，用一个unsigned char来表示文件描述符，所以只能表示0～255。
在网络程序的开发中，每一个网络连接也都占用一个文件描述符，如果程序打开了很多Socket连接（典型的例子就是使用了连接池技术），那么程序运行的时候可能用fopen打不开文件。
解决这个问题，可以采用一下几种方法：
1． 升级为64位系统或采用采用64位方式编译程序
2． 使用sys/io.h中的函数操作文件
3． 采用文件池技术，预留一部分文件描述符（3～255之间的），使用freopen函数来重用这些描述符。
至于采用哪种方法或者是否考虑系统中处理这个问题，就要视具体的情况而定了，那些不受这个限制影响的程序，可以不考虑这个问题。
1.2.2 进程和线程的限制
一般的操作系统对每个进程和线程可以使用的资源数都有限制，比如一个进程可以创建的线程数，一个进程可以打开的文件描述符的数量，进程和线程栈大小的限制和默认值等。
针对这些问题，首先要分析和考虑你的系统是一个什么样的规模，会不会收到这些限制的影响，如果需求大于系统的限制，可以通过适当的调整系统参数来解决，如果还不能解决，就得考虑采用多进程的方式来解决。
对于进程和线程的栈空间大小的限制，主要是线程栈空间的问题。一般的系统都有默认的线程栈空间大小，而且不同操作系统的默认值可能不同。在通常情况下，这些对程序没有影响，但是当程序的层次结构比较复杂，使用了过多的本地变量，这个限制可能就会对程序产生影响，导致栈空间溢出，这是一个比较严重的问题。不能通过调整系统参数来解决这个问题，但是可以通过相应的函数，在程序里面指定创建线程的栈空间的大小。但是具体该调整的数值应该适可而止，而不是越大越好。 因为线程的栈空间过大的时候，就会影响到可创建线程的数量，虽然远没有达到系统多线程数的限制，但却可能因为系统资源占用过多导致分配内存失败。
Linux的线程是通过进程实现的，实际上是假的线程。如果程序只在Linux下运行，就可以考虑直接使用多进程技术来代替多线程，因为在Linux下多线程并不能带来多线程相对于多进程的优势。
1.2.3 网络通信能力的限制
对于网络编程来说，性能是最主要的因素。系统为了提高网络通信的性能，提供了很多辅助的技术，其中等待队列就是其中之一。
对 于程序来说，在一个时间点只能处理一个网络连接请求，而如果同时来了多个网络连接请求的话，就会有很多请求失败。为了解决这个问题，操作系统提供了等待队 列技术，就是处理不上的连接请求先放到系统的等待队列中，这样就可以提高网络连接的成功率。等待队列的创建也需要消耗系统资源，因此系统对等待队列的大小 都有限制，程序中可以通过函数设定等待队列的大小，但是不能超过系统的硬性限制。下面列出了几个操作系统的最大等待队列的大小：
操作系统
最大等待队列
Windows 2000 Server
200
Windows XP Home
5
Solaris E250
128
上 表中只简单列出了几个操作系统的等待队列参数，其他系统暂位列出，如果有兴趣可以自己作个简单的程序测试一下。所以这个问题就跟具体的系统环境有关了，不 过我们可以在系统连接池的基础上再做一些工作，采用连接缓冲池技术。就是接受到网络连接请求以后，提交给出去线程处理的之前，先放到一个缓冲池中。这样可 以接受更多的连接请求等待处理，能一定程度的提高系统的连接成功率。不过，跟系统的等待队列不同，这是通过软件方式实现的等待队列，而系统提供的连接池是 从操作系统级来解决问题的，更接近硬件层次，所以效率肯定会不同。面对这类问题，首先还是得以调整系统连接池的大小，然后再采用其他辅助手段。
1.2.4 容错性的影响
采 用C/C++开发程序，缓冲区溢出的错误非常普遍，但是系统运行程序的时候，对待运行期出现的这些错误的处理能力都不相同。总的来说，Windows系统 的容错性最强，尤其是Debug版的程序，系统都加入了一些保护机制，能够保证出现一些小的错误以后，程序仍能够正常运行。Unix平台下面要求的就严格 一些，有些系统更是容不得一点沙子，有一点错误就会出现宕机现象，这些跟操作系统的内存分配机制有关。Windows平台的程序分配内存的时候，一般都会 多分出一些字节用于对齐，如果缓冲区溢出的不是太多，就不回对内存中其他变量的值造成影响，因此程序也能够正常运行。但是这种保护机制会带来更多的系统开 销。这就是Windows程序移植到Unix下面稳定性降低的主要原因之一，也是为什么Windows系统会消耗那么多系统资源的原因。
要解决这类问题，就要进行更严格的测试和代码检查。同时，借助相关的测试工具，找出系统中隐藏的潜在的问题，不能放过任何一个可能产生的错误，尤其是编译过程中发现的警告信息。当然，这些工作都应该再移植前做的很充分，在移植后更应该加大测试的力度。
1.3 图形用户界面
Windows 和Unix 图形模型差异极大，这点是Unix和Windows程序开发最大的差别。UNIX 使用X Window 系统GUI，而Windows 使用GDI。虽然在概念上类似，但是X API 和GDI API 之间没有简单的对应。在Windows下面可以通过MFC等类库很方便的开发出图形用户界面的程序，而Unix下相对来说就麻烦了些，缺少哪种所见即所得 的好的开发工具。Unix下的GUI程序开发，是一个比较复杂的过程，这里就不在详细介绍。如果要进行Unix下面GUI程序的开发的话，可以单独去查找 相关的文档。
1.4 并发处理
并发处理包括多进程和多线程的概念，Windows和Unix的并发处理差别也比较大，但是基本上都能找到一组对应的函数来实现类似的功能。
在Windows 下: 创建进程和线程可以通过调用Windows的API来完成，或者通过调用MFC提供的并发处理类库来实现。
在Unix下面:创建进程通常使用fork函 数。
这跟Windows下面的多进程概念有所不同，相当于在当前位置给当前进程创建一个副本；而Windows下的创建进程大都是创建一个新的进程。
Unix下的多线程操作，通过一组线程函数来完成，通常我们使用POSIX 的PTHREAD线程库来创建线程，但是在不同的Unix分支系统中，都包含又自己的本地线程库。如在Solaris下面的本地线程库，是一组以thr_ 开头的函数，而POSIX的线程函数一般都已pthread_开头。虽然有两种不同的线程库供我们选择，但在某一个特定的系统下，他们的实现实质都是一样 的，而且基本上都能够找到对应的函数。为了程序的可移植性，建议采用POSIX的线程库。这是大多数Unix系统都支持的线程库，但是不同系统下实现的功 能可能有所差别，可能只是实现了这个函数库的一个子集。
在有些Unix系统下，没有实现线程库，如SCO Unix，系统只提供多进程的开发方式。但是，如果为了实现程序代码的统一性，我们可以采用第三方提供的线程库。这里有一个叫FSU-threads的线 程库供我们选择。这个线程库中实现了POSIX中定义的线程函数，而且是开源的，可以支持SunOS 4.1.x, Solaris 2.x, SCO UNIX, FreeBSD, Linux等系统。除此之外，还有ZThreads线程库等。
在Windows 的线程库中，实现了互斥（Mutex）、事件(Event)、信号量(Semaphore)等同步对象，用于实现线程之间的同步。（还有临界区 add by jia）
在Unix下面，线程同 步主要使用互斥（mutex）和条件变量(cond)，其中条件变量可以实现事件和信号量的功能。另外， POSIX还定义了一套信号量函数，跟线程函数不同，是一组以sem_开头的函数（POSIX 1003.1b semaphores）。但是这套函数就不想POSIX线程函数支持的那么广泛了，比如在AIX上就不支持POSIX的信号量函数，不过AIX系统下有另 一组函数来实现信号量的功能（SystemV semaphores）。在很多Unix系统中，同时支持POSIX的信号量和SystemV的信号量，在Solaris下面还有一套自己的本地函数来实 现信号量。下面分别列出Unix系统中的用于并发处理的主要的函数。
进程
fork 创建进程
POSIX线程库
pthread_create 创建一个信的线程
pthread_attr_init 初始化一个线程属性对象
pthread_attr_destroy 释放一个线程属性对象
pthread_exit 终止执行调用的线程
pthread_join 把当前调用线程挂起，直到目标线程结束
pthread_setschedparam 设置线程的调度策略和优先级
pthread_getschedparam 获得线程的调度策略和优先级
pthread_sigmask 改变/检查调用线程的信号掩码
pthread_kill 发送信号到另一个线程
pthread_self 返回当前线程的ID
pthead_mutex_init 初始化一个互斥量
pthread_mutexattr_init 初始化互斥量的属性对象
pthread_mutex_lock 给一个互斥量加锁，如果互斥量已经被别的线程锁定，调用线程挂起，直到别的线程释放
pthread_mutex_unlock 释放互斥量（解锁）
ptherad_mutex_destroy 销毁一个互斥量
pthread_cond_init 初始化一个条件变量
pthread_condattr_init 初始化一个条件变量的属性对象
pthread_cond_wait 阻塞在一个条件变量上
pthread_cond_signal 解除下一个线程在条件变量的阻塞
pthread_cond_boradcast 解除所有线程在这个条件变量上的阻塞
pthread_cond_destroy 销毁一个条件变量
pthread_cancel 请求结束一个线程
Solaris本地线程库
thr_create 创建一个新线程
thr_exit 终止调用线程
thr_join 把当前调用线程挂起，直到目标线程结束
thr_yield 用当前线程创建出另一个线程
thr_suspend 挂起一个指定的线程
thr_continue 恢复一个被挂起的线程
thr_setprio 修改线程的优先级
thr_getprio 获得线程的优先级
thr_sigsetmask 改变/检查调用线程的信号掩码
thr_kill 发送信号到另一个线程
thr_self 返回当前线程的ID
thr_main 标记为主线程
thr_mutex_init 初始化一个互斥量
thr_mutex_lock 给一个互斥量加锁，如果互斥量已经被别的线程锁定，调用线程挂起，直到别的线程释放
thr_mutex_unlock 释放互斥量（解锁）
thr_mutex_destroy 销毁一个条互斥量
thr_cond_init 初始化一个条件变量
thr_cond_wait 阻塞在一个条件变量上
thr_cond_signal 解除下一个线程在条件变量的阻塞
thr_cond_boradcast 解除所有线程在这个条件变量上的阻塞
thr_cond_destroy 销毁任何状态的条件变量
rwlock_init 初始化一个读写锁
rw_rdlock 获得一个读写锁的读锁定
rw_wrlock 获得一个读写锁的写锁定
rw_unlock 解锁一个读写锁
POSIX信号量
sem_init 初始化一个信号量
sem_destroy 销毁一个信号量
sem_wait 等待获得一个信号量，获得后信号量的值减1，如果当前信号量值位0，当前线程阻塞，支持有别的线程释放信号量
sem_trywait 尝试获得一个信号量，获得后信号量的值减1，如果当前信号量值位0，返回失败
sem_post 释放一个信号量
sem_getvalue 获得指定信号量的值
System V信号量
javascript:if(confirm('http://personal.xfol.com/~rezaie/api/ipc/man.cgi@semctl%20%20""n""nThis%20file%20was%20not%20retrieved%20by%20Teleport%20Pro,%20because%20the%20server%20reports%20that%20this%20file%20cannot%20be%20found.%20%20""n""nDo%20you%20want%20to%20open%20it%20from%20the%20server?'))window.location='http://personal.xfol.com/%7Erezaie/api/ipc/man.cgi@semctl'>semctl 对信号量进行一系列的控制
javascript:if(confirm('http://personal.xfol.com/~rezaie/api/ipc/man.cgi@semget%20%20""n""nThis%20file%20was%20not%20retrieved%20by%20Teleport%20Pro,%20because%20the%20server%20reports%20that%20this%20file%20cannot%20be%20found.%20%20""n""nDo%20you%20want%20to%20open%20it%20from%20the%20server?'))window.location='http://personal.xfol.com/%7Erezaie/api/ipc/man.cgi@semget'>semget 创建一个信号量，成功时返回信号的ID
javascript:if(confirm('http://personal.xfol.com/~rezaie/api/ipc/man.cgi@semop%20%20""n""nThis%20file%20was%20not%20retrieved%20by%20Teleport%20Pro,%20because%20the%20server%20reports%20that%20this%20file%20cannot%20be%20found.%20%20""n""nDo%20you%20want%20to%20open%20it%20from%20the%20server?'))window.location='http://personal.xfol.com/%7Erezaie/api/ipc/man.cgi@semop'>semop 对信号进行操作
Solaris的本地信号量，更接近于操作系统中我们学到的PV操作的信号灯
sema_init 初始化一个信号灯(信号量)
sema_destroy 销毁一个信号灯
sema_p 执行信号灯的P操作
sema_p_sig 跟sema_p类似，当阻塞再这个函数的时候，如果线程收到一个信号，函数退出
sema_tryp 尝试执行信号灯的P操作
sema_v 执行信号灯的V操作
为了方便使用，我在开发的过程中已经把上面常用的函数都封装成了类，兼容Windows和各种常见的Unix系统，而且网上还有很多这方面的代码资源可用。如果感兴趣的话可以向我索要。
1.5 网络通信
Socket (中文译名：套接字)最初在Unix上出现,并很快成为Unix上最流行的网络编程接口之一。后来，微软将它引入到Windows中并得到实现,于是从 Windows 95、WinNT4开始,系统就内置了Winsock1.1,后来到了Windows98、Windows2000,它内置的Winsock DLL更新为Winsock2.2。
Windows 下的Socket函数大体上和Unix下的Socket函数差不多，函数名称很参数用法都类似，只有一些细微的差别，某些参数的意义不同，而且对于 Socket的属性控制也不太一样。Windows下面还对Socket函数进行了封装，有一系列相关类可用使用，简化网络编程的复杂性。Unix本身没 有这些类库，但是我们也已经积累了很多这方面的经验和资源。我们有一组现成的类对Windows和Unix下的Socket函数进行了封装，上层只需要简 单的调用即可，不用关心底层的差别。而且，这套类库也可以同时支持多种平台，可移植性非常好。
关于Socket开发就简单说这些，想深入了解的话请参考介绍Socket编程的一些相关资料。
1.2 操作系统特性的差异不同的操作系统中都存在一些系统的限制，如打开文件句柄数的限制、Socket等待队列的限制、进程和线程堆栈大小的限制等，因此在开发的过程中，必须考虑 到这些限制因素对程序的影响。当然，有些限制参数可以适当的调整，这就需要在发布程序的时候加以声明。另外，操作系统的容错性也对程序有影响。下面分别进 行讨论。 1.2.1 文件描述符的限制文件描述符最初是Unix下的一个概念，在Unix系统中，用文件描述符来表示文件、打开的socket连接等，跟Windows下HANDLE的概念类 似。文件描述符是一种系统资源，系统对每个进程可以分配的文件描述符数量都有限制。以Solaris为例，默认情况下每个进程可以打开的文件描述符为 1024个，系统的硬限制是8192（具体的值跟版本有关），也就是说可以调整到8192。在Unix系统下使用ulimit命令来获得系统的这些限制参 数。一般情况下，这都是够用的，但是有一个例外，在32为的Solaris程序中，使用标准输入输出函数（stdio）进行文件的操作，最大的文件描述符不能超过256。比如说用fopen打开文件，除去系统占用的3个文件描述符（stdin、stdout和stderr），程序中只能再同时打开253个 文件。如果使用open函数来打开文件，就没有这个限制，但是就不能够使用stdio中的那些函数进行操作了，是程序的通用性和灵活性有所降低。这是因为 在stdio的FILE结构中，用一个unsigned char来表示文件描述符，所以只能表示0～255。 在网络程序的开发中，每一个网络连接也都占用一个文件描述符，如果程序打开了很多Socket连接（典型的例子就是使用了连接池技术），那么程序运行的时候可能用fopen打不开文件。 解决这个问题，可以采用一下几种方法： 1． 升级为64位系统或采用采用64位方式编译程序 2． 使用sys/io.h中的函数操作文件 3． 采用文件池技术，预留一部分文件描述符（3～255之间的），使用freopen函数来重用这些描述符。 至于采用哪种方法或者是否考虑系统中处理这个问题，就要视具体的情况而定了，那些不受这个限制影响的程序，可以不考虑这个问题。 1.2.2 进程和线程的限制一般的操作系统对每个进程和线程可以使用的资源数都有限制，比如一个进程可以创建的线程数，一个进程可以打开的文件描述符的数量，进程和线程栈大小的限制和默认值等。 针对这些问题，首先要分析和考虑你的系统是一个什么样的规模，会不会收到这些限制的影响，如果需求大于系统的限制，可以通过适当的调整系统参数来解决，如果还不能解决，就得考虑采用多进程的方式来解决。 对于进程和线程的栈空间大小的限制，主要是线程栈空间的问题。一般的系统都有默认的线程栈空间大小，而且不同操作系统的默认值可能不同。在通常情况下，这些对程序没有影响，但是当程序的层次结构比较复杂，使用了过多的本地变量，这个限制可能就会对程序产生影响，导致栈空间溢出，这是一个比较严重的问题。不能通过调整系统参数来解决这个问题，但是可以通过相应的函数，在程序里面指定创建线程的栈空间的大小。但是具体该调整的数值应该适可而止，而不是越大越好。 因为线程的栈空间过大的时候，就会影响到可创建线程的数量，虽然远没有达到系统多线程数的限制，但却可能因为系统资源占用过多导致分配内存失败。
