在C++中调用C编译器编译过的函数时，为什么要使用"extern C"？_1.在c++程序中调用被c 编译器编译后的函数,为什么要加extern “c”?

（2）在C中引用C++语言中的函数和变量时，C++的头文件需添加extern "C"，但是在C语言中不能直接引用声明了extern "C"的该头文件，应该仅将C文件中将C++中定义的extern "C"函数声明为extern类型。

1、SendMessage、PostMessage的运行机制
SendMessage可以理解为，SendMessage函数发送消息，等待消息处理完成后，SendMessage才返回。稍微深入一点，是等待窗口处理函数返回后，SendMessage就返回了。
PostMessage可以理解为，PostMessage函数发送消息，不等待消息处理完成，立刻返回。稍微深入一点，PostMessage只管发送消息，消息有没有被送到则并不关心，只要发送了消息，便立刻返回。
对于写一般Windows程序的程序员来说，能够这样理解也就足够了。

2、GetMessage()和PeekMessage()有什么区别？

 GetMessage(LPMSG lpMsg, HWND hWnd,   UINT wMsgFilterMin,   UINT wMsgFilterMax)
PeekMessage(LPMSG lpMsg, HWND hWnd,   UINT wMsgFilterMin,   UINT wMsgFilterMax,UINT wRemoveMsg)
参数wRemoveMsg的作用是指定消息获取的方式，如果设为PM_NOREMOVE,那么消息将不会从消息队列中被移出，如果设为PM_REMOVE，那么消息将会从消息队列中被移出；
    两个函数主要有以下两个区别: 
    1.GetMessage将等到有合适的消息时才返回,而PeekMessage只是撇一下消息队列。 
    2.GetMessage会将消息从队列中删除,而PeekMessage可以设置最后一个参数wRemoveMsg来决定是否将消息保留在队列中。
    在Windows的内部，GetMessage和PeekMessage执行着相同的代码。而两者最大的不同之处则体现在没有任何消息返回到应用程序的情况下。在此种情况下，PeekMessage会返回一个空值到应用程序，GetMessage会在此时让应用程序休眠。

举例说明Windows中有哪些同步对象（或锁），在什么情况下使用这些同步对象？

       在windows平台下，用于对多线程（包括进程）之间的同步保护机制，基本上有这么几种：
1）Critical Section对象（临界区） 2）Event对象（事件） 3）Mutex对象（互斥量） 4） Semaphore对象（信号量）。
本文的着眼点在于：总结出这些同步保护机制的一些明显的行为特征。
       以下我们所讨论的这些行为特征，是对并发的进/线程之间的同步保护机制的一般描述，本文用windows平台作为一个典型的例子。 基于这一些行为特征，对本文提及的这四种同步对象做一个分类。
另外，在这里，我们把这四种同步对象，统统称为“锁”，以便于接下来的讨论。
第一、保护与同步。
        在这里要强调的是：保护与同步是两个不同的概念。而我们经常会混合这两个概念。保护是指在多线程的环境下对共享资源的保护。这样的共享资源大多数情况下是一段内存块，它会被很多线程试图访问和修改。而同步更多的强调的是线程之间的协作，协同工作是需要同步支持的。
基于这一性质，我们可以看出：Critical Section对象其本质更多的强调的是保护，而Event对象、Mutex对象与Semaphore对象更多的强调的是同步。不过，这样的区别，只是概念上的区别，其本身不会对程序本身产生影响。
第二、锁的等待超时
       在开发并发的多进/线程程序时，为了避免死锁之类的问题，引入了“等超时“的概念，即当一个线程需要获得一个锁来执行某些代码的时候，它可以在所等待的锁上设置超时值。如果在确定的时间（超时值）内无法获得该锁，它可以选择放弃执行该段代码的权利，这样可以在一定程度上避免出现死锁的问题。这就是锁的等待超时的基本含义。基于这一行为特征，我们来对上面四种同步对象做一个划分：Critical Section对象是无法设置等待超时的，而其他三个对象则可以设置等待超时。从这一点来讲，在使用Critical Section对象时，由于在等待进入关键代码段时无法设置等待超时，很容易造成死锁。
第三、线程锁与进程锁
        这里所说的线程锁指的是该锁只在一个进程的所有线程中可见，而进程锁指的是该锁可以被不同的进程所访问，可用于进程间的同步与互斥。当然进程锁仍然可以被用于同一个进程的不同线程之间的同步与互斥。进程锁的概念是大于线程锁的。基于这一特点划分的话，Critical Section对象是线程锁，而其他三个对象是进程锁。这一点从本质上来分析，Critical Section对象是用户态模式下面实现线程同步的方法，而其他三个对象均是内核对象。内核对象机制的适应性远远优于用户方式机制。实际上，内核对象机制的唯一不足之处在于它的速度比较慢，这是因为当调用内核机制对象时，必须从用户方式转到内核方式。这样的转换需要付出很大的代价，是一件很费时的操作。在X86平台上,这样往返一次需要占用1000个CPU周期(这并不包括执行内核方式的代码)。当然需要注意的是：使用Critical Section对象并不意味着线程不会陷入核心态执行。当一个线程试图进入另一个线程拥有的关键代码段时,该线程就会进入等待状态。这意味着：该线程必须从用户态转为核心态。(为了提高这一方面的性能,Microsoft将循环锁的概念纳入到了Critical Section对象中,该线程可以有选择地不进入核心态等待.具体请参阅MSDN)
第四、锁的递归特质
        所谓递归锁指的是当一个线程拥有一个同步锁时,而递归地想再次取得该锁.如果这次获得操作不会阻塞当前线程的执行,则称该锁为递归锁.递归锁主要是在"保护"的概念上提出的,而"保护"概念下的锁包括Critical Section对象和Mutext 对象.这两种锁在Windows平台上都是递归锁。需要注意的是：调用线程获得几次递归锁必须释放几次递归锁。
第五、读写锁
       读写锁允许高效的并发的访问多线程环境下的共享资源。对于一种共享资源,多个线程可以获得读锁,共享地读该共享资源。而在同一时刻,只允许一个线程拥有写锁改变该共享资源.这就是读写锁的概念。很遗憾的是在Windows平台上没有这样的读写锁,你需要自己去实现。