深入浅出Win32多线程程序设计之线程通信

信号量

　　信号量是维护0到指定最大值之间的同步对象。信号量状态在其计数大于0时是有信号的，而其计数是0时是无信号的。信号量对象在控制上可以支持有限数量共享资源的访问。

　　信号量的特点和用途可用下列几句话定义：

　　（1）如果当前资源的数量大于0，则信号量有效；

　　（2）如果当前资源数量是0，则信号量无效；

　　（3）系统决不允许当前资源的数量为负值；

　　（4）当前资源数量决不能大于最大资源数量。

　　创建信号量

HANDLE CreateSemaphore ( 　PSECURITY_ATTRIBUTE psa, 　LONG lInitialCount, //开始时可供使用的资源数 　LONG lMaximumCount, //最大资源数 PCTSTR pszName);

　　释放信号量

　　通过调用ReleaseSemaphore函数，线程就能够对信标的当前资源数量进行递增，该函数原型为：

BOOL WINAPI ReleaseSemaphore( 　HANDLE hSemaphore, 　LONG lReleaseCount, //信号量的当前资源数增加lReleaseCount 　LPLONG lpPreviousCount );

　　打开信号量

　　和其他核心对象一样，信号量也可以通过名字跨进程访问，打开信号量的API为：

HANDLE OpenSemaphore ( 　DWORD fdwAccess, 　BOOL bInherithandle, 　PCTSTR pszName );

　　互锁访问

　　当必须以原子操作方式来修改单个值时，互锁访问函数是相当有用的。所谓原子访问，是指线程在访问资源时能够确保所有其他线程都不在同一时间内访问相同的资源。

　　请看下列代码：

int globalVar = 0; DWORD WINAPI ThreadFunc1(LPVOID n) { 　globalVar++; 　return 0; } DWORD WINAPI ThreadFunc2(LPVOID n) { 　globalVar++; 　return 0; }

　　运行ThreadFunc1和ThreadFunc2线程，结果是不可预料的，因为globalVar++并不对应着一条机器指令，我们看看globalVar++的反汇编代码：

00401038 mov eax,[globalVar (0042d3f0)] 0040103D add eax,1 00401040 mov [globalVar (0042d3f0)],eax

　　在"mov eax,[globalVar (0042d3f0)]" 指令与"add eax,1" 指令以及"add eax,1" 指令与"mov [globalVar (0042d3f0)],eax"指令之间都可能发生线程切换，使得程序的执行后globalVar的结果不能确定。我们可以使用InterlockedExchangeAdd函数解决这个问题：

int globalVar = 0; DWORD WINAPI ThreadFunc1(LPVOID n) { 　InterlockedExchangeAdd(&globalVar,1); 　return 0; } DWORD WINAPI ThreadFunc2(LPVOID n) { 　InterlockedExchangeAdd(&globalVar,1); 　return 0; }

　　InterlockedExchangeAdd保证对变量globalVar的访问具有"原子性"。互锁访问的控制速度非常快，调用一个互锁函数的CPU周期通常小于50，不需要进行用户方式与内核方式的切换（该切换通常需要运行1000个CPU周期）。

　　互锁访问函数的缺点在于其只能对单一变量进行原子访问，如果要访问的资源比较复杂，仍要使用临界区或互斥。

　　可等待定时器

　　可等待定时器是在某个时间或按规定的间隔时间发出自己的信号通知的内核对象。它们通常用来在某个时间执行某个操作。

　　创建可等待定时器

HANDLE CreateWaitableTimer( 　PSECURITY_ATTRISUTES psa, 　BOOL fManualReset,//人工重置或自动重置定时器 PCTSTR pszName);

　　设置可等待定时器

　　可等待定时器对象在非激活状态下被创建，程序员应调用 SetWaitableTimer函数来界定定时器在何时被激活：

BOOL SetWaitableTimer( 　HANDLE hTimer, //要设置的定时器 　const LARGE_INTEGER *pDueTime, //指明定时器第一次激活的时间 　LONG lPeriod, //指明此后定时器应该间隔多长时间激活一次 　PTIMERAPCROUTINE pfnCompletionRoutine, 　PVOID PvArgToCompletionRoutine, BOOL fResume);

　　取消可等待定时器

BOOl Cancel WaitableTimer( 　HANDLE hTimer //要取消的定时器 );

　　打开可等待定时器

　　作为一种内核对象，WaitableTimer也可以被其他进程以名字打开：

HANDLE OpenWaitableTimer ( 　DWORD fdwAccess, 　BOOL bInherithandle, 　PCTSTR pszName );

　　实例

　　下面给出的一个程序可能发生死锁现象：

#include <windows.h> #include <stdio.h> CRITICAL_SECTION cs1, cs2; long WINAPI ThreadFn(long); main() { 　long iThreadID; 　InitializeCriticalSection(&cs1); 　InitializeCriticalSection(&cs2); 　CloseHandle(CreateThread(NULL, 0, (LPTHREAD_START_ROUTINE)ThreadFn, NULL, 0,&iThreadID)); 　while (TRUE) 　{ 　　EnterCriticalSection(&cs1); 　　printf("\n线程1占用临界区1"); 　　EnterCriticalSection(&cs2); 　　printf("\n线程1占用临界区2"); 　　printf("\n线程1占用两个临界区"); 　　LeaveCriticalSection(&cs2); 　　LeaveCriticalSection(&cs1); 　　printf("\n线程1释放两个临界区"); 　　Sleep(20); 　}; 　return (0); } long WINAPI ThreadFn(long lParam) { 　while (TRUE) 　{ 　　EnterCriticalSection(&cs2); 　　printf("\n线程2占用临界区2"); 　　EnterCriticalSection(&cs1); 　　printf("\n线程2占用临界区1"); 　　printf("\n线程2占用两个临界区"); 　　LeaveCriticalSection(&cs1); 　　LeaveCriticalSection(&cs2); 　　printf("\n线程2释放两个临界区"); 　　Sleep(20); 　}; }

　　运行这个程序，在中途一旦发生这样的输出：

　　线程1占用临界区1

　　线程2占用临界区2

　　或

　　线程2占用临界区2

　　线程1占用临界区1

　　或

　　线程1占用临界区2

　　线程2占用临界区1

　　或

　　线程2占用临界区1

　　线程1占用临界区2

　　程序就"死"掉了，再也运行不下去。因为这样的输出，意味着两个线程相互等待对方释放临界区，也即出现了死锁。

　　如果我们将线程2的控制函数改为：

long WINAPI ThreadFn(long lParam) { 　while (TRUE) 　{ 　　EnterCriticalSection(&cs1); 　　printf("\n线程2占用临界区1"); 　　EnterCriticalSection(&cs2); 　　printf("\n线程2占用临界区2"); 　　printf("\n线程2占用两个临界区"); 　　LeaveCriticalSection(&cs1); 　　LeaveCriticalSection(&cs2); 　　printf("\n线程2释放两个临界区"); 　　Sleep(20); 　}; }

　　再次运行程序，死锁被消除，程序不再挡掉。这是因为我们改变了线程2中获得临界区1、2的顺序，消除了线程1、2相互等待资源的可能性。

　　由此我们得出结论，在使用线程间的同步机制时，要特别留心死锁的发生。

查看本文来源