1 官网

1.1 POSIX Threads (pthreads) for Win32

http://www.sourceware.org/pthreads-win32/

下载地址：ftp://sourceware.org/pub/pthreads-win32/

1.2 当前最新版本为：PTHREADS-WIN32 RELEASE 2.9.1 (2012-05-27)

下载到的文件为pthreads-w32-2-9-1-release.zip

解压到“pthreads-w32-2-9-1-release”目录，里面有三个子目录：

[plain] view plaincopy

print?

1. pre-build.2
2. pthreads.2
3. QueueUserAPCEx

Pthreads.2 里面包含了pthreads 的源代码；

Pre-build.2 里面包含了include和 lib 分别包含了pthreads for win32 的头文件和库文件(包括动态连接库)。以下做法不推荐:将include 和lib 里面的内容分别复制到你的编译器的include 和 lib 目录，同时将lib 目录中的 dll 文件copy 到操作系统的system32 文件夹中或应用程序执行目录。

QueueUserAPCEx 里面是一个alert的driver，编译需要DDK ，默认vs2013 没有安装。Windows Device Driver Kit (NTDDK.h) 需要额外单独安装。

2 源代码编译

虽然源码包里提供了vc6的项目文件, 但是我不推荐直接打开, 而推荐用nmake.默认的会告诉你一堆nmake参数的. 
注：请仔细阅读：

[plain] view plaincopy

print?

1. pthreads-w32-2-9-1-release\pthreads.2\README（系列文件）
2. pthreads-w32-2-9-1-release\pthreads.2\tests\README

2.1 命令选取：

参考文档：pthreads-w32-2-9-1-release\pthreads.2\Nmakefile

编译库我选取以下4个命令：

[plain] view plaincopy

print?

1. nmake clean VC-static (to build the MSVC static lib with C cleanup code)
2. nmake clean VC-static-debug (to build the debug MSVC static lib with C cleanup code)
3. nmake clean VC-inlined (to build the MSVC inlined dll with C cleanup code)
4. nmake clean VC-inlined-debug (to build the debug MSVC inlined dll with C cleanup code)

参考文档：pthreads-w32-2-9-1-release\pthreads.2\tests\Makefile

测试我选取以下2个命令

[plain] view plaincopy

print?

1. nmake clean VC (to test using VC dll with VC (no EH) applications)
2. nmake clean VC-static (to test using VC static lib with VC (no EH) applications)

2.2 Nmakefile文件修改

将pthreads-w32-2-9-1-release\pthreads.2\Nmakefile文件中的以下语句

[plain] view plaincopy

print?

1. install:
2. copy pthread*.dll $(DLLDEST)
3. copy pthread*.lib $(LIBDEST)
4. copy pthread.h $(HDRDEST)
5. copy sched.h $(HDRDEST)
6. copy semaphore.h $(HDRDEST)

替换为：

[plain] view plaincopy

print?

1. install:
2. if not exist $(DEVROOT) mkdir $(DEVROOT)
3. if not exist $(DLLDEST) mkdir $(DLLDEST)
4. if not exist $(LIBDEST) mkdir $(LIBDEST)
5. if not exist $(HDRDEST) mkdir $(HDRDEST)
6. xcopy /H /Y /R /I /V /K pthread*.dll $(DLLDEST)
7. xcopy /H /Y /R /I /V /K pthread*.pdb $(LIBDEST)
8. copy /Y pthread*.lib $(LIBDEST)
9. copy /Y pthread.h $(HDRDEST)
10. copy /Y sched.h $(HDRDEST)
11. copy /Y semaphore.h $(HDRDEST)

2.3 编译命令

通过对“pthreads-w32-2-9-1-release\pthreads.2\Nmakefile”分析，本人对编译命令我稍作修改。

x64编译：

[plain] view plaincopy

print?

1. nmake realclean VC-inlined-debug
2. nmake DEVROOT=D:\comm\pthreads\debug_x64 install
3. nmake realclean VC-inlined
4. nmake DEVROOT=D:\comm\pthreads\release_x64 install
5. cd tests
6. nmake clean VC
7. nmake clean
8. cd ..
9. nmake realclean VC-static-debug
10. nmake DEVROOT=D:\comm\pthreads\debug_x64_static install
11. nmake realclean VC-static
12. nmake DEVROOT=D:\comm\pthreads\release_x64_static install
13. cd tests
14. nmake clean VC-static
15. nmake clean
16. cd ..

x86编译：

[plain] view plaincopy

print?

1. nmake realclean VC-inlined-debug
2. nmake DEVROOT=D:\comm\pthreads\debug_x86 install
3. nmake realclean VC-inlined
4. nmake DEVROOT=D:\comm\pthreads\release_x86 install
5. cd tests
6. nmake clean VC
7. nmake clean
8. cd ..
9. nmake realclean VC-static-debug
10. nmake DEVROOT=D:\comm\pthreads\debug_x86_static install
11. nmake realclean VC-static
12. nmake DEVROOT=D:\comm\pthreads\release_x86_static install
13. cd tests
14. nmake clean VC-static
15. nmake clean
16. cd ..

两步合一（只编译库）：

x64编译：

[plain] view plaincopy

print?

1. nmake realclean VC-inlined-debug DEVROOT=D:\comm\pthreads\debug_x64 install
2. nmake realclean VC-inlined DEVROOT=D:\comm\pthreads\release_x64 install
3. nmake realclean VC-static-debug DEVROOT=D:\comm\pthreads\debug_x64_static install
4. nmake realclean VC-static DEVROOT=D:\comm\pthreads\release_x64_static install

x86编译：

[cpp] view plaincopy

print?

1. nmake realclean VC-inlined-debug DEVROOT=D:\comm\pthreads\debug_x86 install
2. nmake realclean VC-inlined DEVROOT=D:\\comm\pthreads\release_x86 install
3. nmake realclean VC-static-debug DEVROOT=D:\comm\pthreads\debug_x86_static install
4. nmake realclean VC-staticDEVROOT=D:\comm\pthreads\release_x86_static install

3 pthread-win32应用注意事项

注：在此请仔细阅读pthreads-w32-2-9-1-release\pthreads.2\README文件
3.1 pthreadVCE或pthreadGCE使用注意事项

原文摘录

[plain] view plaincopy

print?

1. [If you use either pthreadVCE or pthreadGCE]
2. 1. [See also the discussion in the FAQ file - Q2, Q4, and Q5]
3. If your application contains catch(...) blocks in your POSIX
4. threads then you will need to replace the "catch(...)" with the macro
5. "PtW32Catch", eg.
6. #ifdef PtW32Catch
7. PtW32Catch {
8. ...
9. }
10. #else
11. catch(...) {
12. ...
13. }
14. #endif
15. Otherwise neither pthreads cancelation nor pthread_exit() will work
16. reliably when using versions of the library that use C++ exceptions
17. for cancelation and thread exit.
18. This is due to what is believed to be a C++ compliance error in VC++
19. whereby you may not have multiple handlers for the same exception in
20. the same try/catch block. GNU G++ doesn't have this restriction.

3.2 Cleanup代码默认形式

原文摘录

[plain] view plaincopy

print?

1. Cleanup code default style
2. --------------------------
3. Previously, if not defined, the cleanup style was determined automatically
4. from the compiler used, and one of the following was defined accordingly:
5. __CLEANUP_SEH   MSVC only
6. __CLEANUP_CXX   C++, including MSVC++, GNU G++
7. __CLEANUP_C C, including GNU GCC, not MSVC
8. These defines determine the style of cleanup (see pthread.h) and,
9. most importantly, the way that cancelation and thread exit (via
10. pthread_exit) is performed (see the routine ptw32_throw()).
11. In short, the exceptions versions of the library throw an exception
12. when a thread is canceled, or exits via pthread_exit(). This exception is
13. caught by a handler in the thread startup routine, so that the
14. the correct stack unwinding occurs regardless of where the thread
15. is when it's canceled or exits via pthread_exit().
16. In this snapshot, unless the build explicitly defines (e.g. via a
17. compiler option) __CLEANUP_SEH, __CLEANUP_CXX, or __CLEANUP_C, then
18. the build NOW always defaults to __CLEANUP_C style cleanup. This style
19. uses setjmp/longjmp in the cancelation and pthread_exit implementations,
20. and therefore won't do stack unwinding even when linked to applications
21. that have it (e.g. C++ apps). This is for consistency with most/all
22. commercial Unix POSIX threads implementations.
23. Although it was not clearly documented before, it is still necessary to
24. build your application using the same __CLEANUP_* define as was
25. used for the version of the library that you link with, so that the
26. correct parts of pthread.h are included. That is, the possible
27. defines require the following library versions:
28. __CLEANUP_SEH   pthreadVSE.dll
29. __CLEANUP_CXX   pthreadVCE.dll or pthreadGCE.dll
30. __CLEANUP_C pthreadVC.dll or pthreadGC.dll
31. It is recommended that you let pthread.h use it's default __CLEANUP_C
32. for both library and application builds. That is, don't define any of
33. the above, and then link with pthreadVC.lib (MSVC or MSVC++) and
34. libpthreadGC.a (MinGW GCC or G++). The reason is explained below, but
35. another reason is that the prebuilt pthreadVCE.dll is currently broken.
36. Versions built with MSVC++ later than version 6 may not be broken, but I
37. can't verify this yet.
38. WHY ARE WE MAKING THE DEFAULT STYLE LESS EXCEPTION-FRIENDLY?
39. Because no commercial Unix POSIX threads implementation allows you to
40. choose to have stack unwinding. Therefore, providing it in pthread-win32
41. as a default is dangerous. We still provide the choice but unless
42. you consciously choose to do otherwise, your pthreads applications will
43. now run or crash in similar ways irrespective of the pthreads platform
44. you use. Or at least this is the hope.

3.3 静态库编译及使用（重中之重）

原文摘录

[plain] view plaincopy

print?

1. Building the library as a statically linkable library
2. -----------------------------------------------------
3. General: PTW32_STATIC_LIB must be defined for both the library build and the
4. application build. The makefiles supplied and used by the following 'make'
5. command lines will define this for you.
6. MSVC (creates pthreadVCn.lib as a static link lib):
7. nmake clean VC-static
8. MinGW32 (creates libpthreadGCn.a as a static link lib):
9. make clean GC-static
10. Define PTW32_STATIC_LIB when building your application. Also, your
11. application must call a two non-portable routines to initialise the
12. some state on startup and cleanup before exit. One other routine needs
13. to be called to cleanup after any Win32 threads have called POSIX API
14. routines. See README.NONPORTABLE or the html reference manual pages for
15. details on these routines:
16. BOOL pthread_win32_process_attach_np (void);
17. BOOL pthread_win32_process_detach_np (void);
18. BOOL pthread_win32_thread_attach_np (void); // Currently a no-op
19. BOOL pthread_win32_thread_detach_np (void);
20. The tests makefiles have the same targets but only check that the
21. static library is statically linkable. They don't run the full
22. testsuite. To run the full testsuite, build the dlls and run the
23. dll test targets.

3.4pthread_win32不可移植的特性及问题(非常重要)

详见pthreads-w32-2-9-1-release\pthreads.2\README.NONPORTABLE文件
原文摘录

[plain] view plaincopy

print?

1. This file documents non-portable functions and other issues.
2. Non-portable functions included in pthreads-win32
3. -------------------------------------------------
4. BOOL
5. pthread_win32_test_features_np(int mask)
6. This routine allows an application to check which
7. run-time auto-detected features are available within
8. the library.
9. The possible features are:
10. PTW32_SYSTEM_INTERLOCKED_COMPARE_EXCHANGE
11. Return TRUE if the native version of
12. InterlockedCompareExchange() is being used.
13. This feature is not meaningful in recent
14. library versions as MSVC builds only support
15. system implemented ICE. Note that all Mingw
16. builds use inlined asm versions of all the
17. Interlocked routines.
18. PTW32_ALERTABLE_ASYNC_CANCEL
19. Return TRUE is the QueueUserAPCEx package
20. QUSEREX.DLL is available and the AlertDrv.sys
21. driver is loaded into Windows, providing
22. alertable (pre-emptive) asyncronous threads
23. cancelation. If this feature returns FALSE
24. then the default async cancel scheme is in
25. use, which cannot cancel blocked threads.
26. Features may be Or'ed into the mask parameter, in which case
27. the routine returns TRUE if any of the Or'ed features would
28. return TRUE. At this stage it doesn't make sense to Or features
29. but it may some day.
30. void *
31. pthread_timechange_handler_np(void *)
32. To improve tolerance against operator or time service
33. initiated system clock changes.
34. This routine can be called by an application when it
35. receives a WM_TIMECHANGE message from the system. At
36. present it broadcasts all condition variables so that
37. waiting threads can wake up and re-evaluate their
38. conditions and restart their timed waits if required.
39. It has the same return type and argument type as a
40. thread routine so that it may be called directly
41. through pthread_create(), i.e. as a separate thread.
42. Parameters
43. Although a parameter must be supplied, it is ignored.
44. The value NULL can be used.
45. Return values
46. It can return an error EAGAIN to indicate that not
47. all condition variables were broadcast for some reason.
48. Otherwise, 0 is returned.
49. If run as a thread, the return value is returned
50. through pthread_join().
51. The return value should be cast to an integer.
52. HANDLE
53. pthread_getw32threadhandle_np(pthread_t thread);
54. Returns the win32 thread handle that the POSIX
55. thread "thread" is running as.
56. Applications can use the win32 handle to set
57. win32 specific attributes of the thread.
58. DWORD
59. pthread_getw32threadid_np (pthread_t thread)
60. Returns the Windows native thread ID that the POSIX
61. thread "thread" is running as.
62. Only valid when the library is built where
63. ! (defined(__MINGW64__) || defined(__MINGW32__)) || defined (__MSVCRT__) || defined (__DMC__)
64. and otherwise returns 0.
65. int
66. pthread_mutexattr_setkind_np(pthread_mutexattr_t * attr, int kind)
67. int
68. pthread_mutexattr_getkind_np(pthread_mutexattr_t * attr, int *kind)
69. These two routines are included for Linux compatibility
70. and are direct equivalents to the standard routines
71. pthread_mutexattr_settype
72. pthread_mutexattr_gettype
73. pthread_mutexattr_setkind_np accepts the following
74. mutex kinds:
75. PTHREAD_MUTEX_FAST_NP
76. PTHREAD_MUTEX_ERRORCHECK_NP
77. PTHREAD_MUTEX_RECURSIVE_NP
78. These are really just equivalent to (respectively):
79. PTHREAD_MUTEX_NORMAL
80. PTHREAD_MUTEX_ERRORCHECK
81. PTHREAD_MUTEX_RECURSIVE
82. int
83. pthread_delay_np (const struct timespec *interval);
84. This routine causes a thread to delay execution for a specific period of time.
85. This period ends at the current time plus the specified interval. The routine
86. will not return before the end of the period is reached, but may return an
87. arbitrary amount of time after the period has gone by. This can be due to
88. system load, thread priorities, and system timer granularity.
89. Specifying an interval of zero (0) seconds and zero (0) nanoseconds is
90. allowed and can be used to force the thread to give up the processor or to
91. deliver a pending cancelation request.
92. This routine is a cancelation point.
93. The timespec structure contains the following two fields:
94. tv_sec is an integer number of seconds.
95. tv_nsec is an integer number of nanoseconds.
96. Return Values
97. If an error condition occurs, this routine returns an integer value
98. indicating the type of error. Possible return values are as follows:
99. 0          Successful completion.
100. [EINVAL]   The value specified by interval is invalid.
101. int
102. pthread_num_processors_np (void)
103. This routine (found on HPUX systems) returns the number of processors
104. in the system. This implementation actually returns the number of
105. processors available to the process, which can be a lower number
106. than the system's number, depending on the process's affinity mask.
107. BOOL
108. pthread_win32_process_attach_np (void);
109. BOOL
110. pthread_win32_process_detach_np (void);
111. BOOL
112. pthread_win32_thread_attach_np (void);
113. BOOL
114. pthread_win32_thread_detach_np (void);
115. These functions contain the code normally run via dllMain
116. when the library is used as a dll but which need to be
117. called explicitly by an application when the library
118. is statically linked. As of version 2.9.0 of the library, static
119. builds using either MSC or GCC will call pthread_win32_process_*
120. automatically at application startup and exit respectively.
121. Otherwise, you will need to call pthread_win32_process_attach_np()
122. before you can call any pthread routines when statically linking.
123. You should call pthread_win32_process_detach_np() before
124. exiting your application to clean up.
125. pthread_win32_thread_attach_np() is currently a no-op, but
126. pthread_win32_thread_detach_np() is needed to clean up
127. the implicit pthread handle that is allocated to a Win32 thread if
128. it calls any pthreads routines. Call this routine when the
129. Win32 thread exits.
130. Threads created through pthread_create() do not need to call
131. pthread_win32_thread_detach_np().
132. These functions invariably return TRUE except for
133. pthread_win32_process_attach_np() which will return FALSE
134. if pthreads-win32 initialisation fails.
135. int
136. pthreadCancelableWait (HANDLE waitHandle);
137. int
138. pthreadCancelableTimedWait (HANDLE waitHandle, DWORD timeout);
139. These two functions provide hooks into the pthread_cancel
140. mechanism that will allow you to wait on a Windows handle
141. and make it a cancellation point. Both functions block
142. until either the given w32 handle is signaled, or
143. pthread_cancel has been called. It is implemented using
144. WaitForMultipleObjects on 'waitHandle' and a manually
145. reset w32 event used to implement pthread_cancel.
146. Non-portable issues
147. -------------------
148. Thread priority
149. POSIX defines a single contiguous range of numbers that determine a
150. thread's priority. Win32 defines priority classes and priority
151. levels relative to these classes. Classes are simply priority base
152. levels that the defined priority levels are relative to such that,
153. changing a process's priority class will change the priority of all
154. of it's threads, while the threads retain the same relativity to each
155. other.
156. A Win32 system defines a single contiguous monotonic range of values
157. that define system priority levels, just like POSIX. However, Win32
158. restricts individual threads to a subset of this range on a
159. per-process basis.
160. The following table shows the base priority levels for combinations
161. of priority class and priority value in Win32.
162. Process Priority Class               Thread Priority Level
163. -----------------------------------------------------------------
164. 1 IDLE_PRIORITY_CLASS                THREAD_PRIORITY_IDLE
165. 1 BELOW_NORMAL_PRIORITY_CLASS        THREAD_PRIORITY_IDLE
166. 1 NORMAL_PRIORITY_CLASS              THREAD_PRIORITY_IDLE
167. 1 ABOVE_NORMAL_PRIORITY_CLASS        THREAD_PRIORITY_IDLE
168. 1 HIGH_PRIORITY_CLASS                THREAD_PRIORITY_IDLE
169. 2 IDLE_PRIORITY_CLASS                THREAD_PRIORITY_LOWEST
170. 3 IDLE_PRIORITY_CLASS                THREAD_PRIORITY_BELOW_NORMAL
171. 4 IDLE_PRIORITY_CLASS                THREAD_PRIORITY_NORMAL
172. 4 BELOW_NORMAL_PRIORITY_CLASS        THREAD_PRIORITY_LOWEST
173. 5 IDLE_PRIORITY_CLASS                THREAD_PRIORITY_ABOVE_NORMAL
174. 5 BELOW_NORMAL_PRIORITY_CLASS        THREAD_PRIORITY_BELOW_NORMAL
175. 5 Background NORMAL_PRIORITY_CLASS   THREAD_PRIORITY_LOWEST
176. 6 IDLE_PRIORITY_CLASS                THREAD_PRIORITY_HIGHEST
177. 6 BELOW_NORMAL_PRIORITY_CLASS        THREAD_PRIORITY_NORMAL
178. 6 Background NORMAL_PRIORITY_CLASS   THREAD_PRIORITY_BELOW_NORMAL
179. 7 BELOW_NORMAL_PRIORITY_CLASS        THREAD_PRIORITY_ABOVE_NORMAL
180. 7 Background NORMAL_PRIORITY_CLASS   THREAD_PRIORITY_NORMAL
181. 7 Foreground NORMAL_PRIORITY_CLASS   THREAD_PRIORITY_LOWEST
182. 8 BELOW_NORMAL_PRIORITY_CLASS        THREAD_PRIORITY_HIGHEST
183. 8 NORMAL_PRIORITY_CLASS              THREAD_PRIORITY_ABOVE_NORMAL
184. 8 Foreground NORMAL_PRIORITY_CLASS   THREAD_PRIORITY_BELOW_NORMAL
185. 8 ABOVE_NORMAL_PRIORITY_CLASS        THREAD_PRIORITY_LOWEST
186. 9 NORMAL_PRIORITY_CLASS              THREAD_PRIORITY_HIGHEST
187. 9 Foreground NORMAL_PRIORITY_CLASS   THREAD_PRIORITY_NORMAL
188. 9 ABOVE_NORMAL_PRIORITY_CLASS        THREAD_PRIORITY_BELOW_NORMAL
189. 10 Foreground NORMAL_PRIORITY_CLASS   THREAD_PRIORITY_ABOVE_NORMAL
190. 10 ABOVE_NORMAL_PRIORITY_CLASS        THREAD_PRIORITY_NORMAL
191. 11 Foreground NORMAL_PRIORITY_CLASS   THREAD_PRIORITY_HIGHEST
192. 11 ABOVE_NORMAL_PRIORITY_CLASS        THREAD_PRIORITY_ABOVE_NORMAL
193. 11 HIGH_PRIORITY_CLASS                THREAD_PRIORITY_LOWEST
194. 12 ABOVE_NORMAL_PRIORITY_CLASS        THREAD_PRIORITY_HIGHEST
195. 12 HIGH_PRIORITY_CLASS                THREAD_PRIORITY_BELOW_NORMAL
196. 13 HIGH_PRIORITY_CLASS                THREAD_PRIORITY_NORMAL
197. 14 HIGH_PRIORITY_CLASS                THREAD_PRIORITY_ABOVE_NORMAL
198. 15 HIGH_PRIORITY_CLASS                THREAD_PRIORITY_HIGHEST
199. 15 HIGH_PRIORITY_CLASS                THREAD_PRIORITY_TIME_CRITICAL
200. 15 IDLE_PRIORITY_CLASS                THREAD_PRIORITY_TIME_CRITICAL
201. 15 BELOW_NORMAL_PRIORITY_CLASS        THREAD_PRIORITY_TIME_CRITICAL
202. 15 NORMAL_PRIORITY_CLASS              THREAD_PRIORITY_TIME_CRITICAL
203. 15 ABOVE_NORMAL_PRIORITY_CLASS        THREAD_PRIORITY_TIME_CRITICAL
204. 16 REALTIME_PRIORITY_CLASS            THREAD_PRIORITY_IDLE
205. 17 REALTIME_PRIORITY_CLASS            -7
206. 18 REALTIME_PRIORITY_CLASS            -6
207. 19 REALTIME_PRIORITY_CLASS            -5
208. 20 REALTIME_PRIORITY_CLASS            -4
209. 21 REALTIME_PRIORITY_CLASS            -3
210. 22 REALTIME_PRIORITY_CLASS            THREAD_PRIORITY_LOWEST
211. 23 REALTIME_PRIORITY_CLASS            THREAD_PRIORITY_BELOW_NORMAL
212. 24 REALTIME_PRIORITY_CLASS            THREAD_PRIORITY_NORMAL
213. 25 REALTIME_PRIORITY_CLASS            THREAD_PRIORITY_ABOVE_NORMAL
214. 26 REALTIME_PRIORITY_CLASS            THREAD_PRIORITY_HIGHEST
215. 27 REALTIME_PRIORITY_CLASS             3
216. 28 REALTIME_PRIORITY_CLASS             4
217. 29 REALTIME_PRIORITY_CLASS             5
218. 30 REALTIME_PRIORITY_CLASS             6
219. 31 REALTIME_PRIORITY_CLASS            THREAD_PRIORITY_TIME_CRITICAL
220. Windows NT:  Values -7, -6, -5, -4, -3, 3, 4, 5, and 6 are not supported.
221. As you can see, the real priority levels available to any individual
222. Win32 thread are non-contiguous.
223. An application using pthreads-win32 should not make assumptions about
224. the numbers used to represent thread priority levels, except that they
225. are monotonic between the values returned by sched_get_priority_min()
226. and sched_get_priority_max(). E.g. Windows 95, 98, NT, 2000, XP make
227. available a non-contiguous range of numbers between -15 and 15, while
228. at least one version of WinCE (3.0) defines the minimum priority
229. (THREAD_PRIORITY_LOWEST) as 5, and the maximum priority
230. (THREAD_PRIORITY_HIGHEST) as 1.
231. Internally, pthreads-win32 maps any priority levels between
232. THREAD_PRIORITY_IDLE and THREAD_PRIORITY_LOWEST to THREAD_PRIORITY_LOWEST,
233. or between THREAD_PRIORITY_TIME_CRITICAL and THREAD_PRIORITY_HIGHEST to
234. THREAD_PRIORITY_HIGHEST. Currently, this also applies to
235. REALTIME_PRIORITY_CLASSi even if levels -7, -6, -5, -4, -3, 3, 4, 5, and 6
236. are supported.
237. If it wishes, a Win32 application using pthreads-win32 can use the Win32
238. defined priority macros THREAD_PRIORITY_IDLE through
239. THREAD_PRIORITY_TIME_CRITICAL.
240. The opacity of the pthread_t datatype
241. -------------------------------------
242. and possible solutions for portable null/compare/hash, etc
243. ----------------------------------------------------------
244. Because pthread_t is an opague datatype an implementation is permitted to define
245. pthread_t in any way it wishes. That includes defining some bits, if it is
246. scalar, or members, if it is an aggregate, to store information that may be
247. extra to the unique identifying value of the ID. As a result, pthread_t values
248. may not be directly comparable.
249. If you want your code to be portable you must adhere to the following contraints:
250. 1) Don't assume it is a scalar data type, e.g. an integer or pointer value. There
251. are several other implementations where pthread_t is also a struct. See our FAQ
252. Question 11 for our reasons for defining pthread_t as a struct.
253. 2) You must not compare them using relational or equality operators. You must use
254. the API function pthread_equal() to test for equality.
255. 3) Never attempt to reference individual members.
256. The problem
257. Certain applications would like to be able to access only the 'pure' pthread_t
258. id values, primarily to use as keys into data structures to manage threads or
259. thread-related data, but this is not possible in a maximally portable and
260. standards compliant way for current POSIX threads implementations.
261. For implementations that define pthread_t as a scalar, programmers often employ
262. direct relational and equality operators on pthread_t. This code will break when
263. ported to an implementation that defines pthread_t as an aggregate type.
264. For implementations that define pthread_t as an aggregate, e.g. a struct,
265. programmers can use memcmp etc., but then face the prospect that the struct may
266. include alignment padding bytes or bits as well as extra implementation-specific
267. members that are not part of the unique identifying value.
268. [While this is not currently the case for pthreads-win32, opacity also
269. means that an implementation is free to change the definition, which should
270. generally only require that applications be recompiled and relinked, not
271. rewritten.]
272. Doesn't the compiler take care of padding?
273. The C89 and later standards only effectively guarrantee element-by-element
274. equivalence following an assignment or pass by value of a struct or union,
275. therefore undefined areas of any two otherwise equivalent pthread_t instances
276. can still compare differently, e.g. attempting to compare two such pthread_t
277. variables byte-by-byte, e.g. memcmp(&t1, &t2, sizeof(pthread_t) may give an
278. incorrect result. In practice I'm reasonably confident that compilers routinely
279. also copy the padding bytes, mainly because assignment of unions would be far
280. too complicated otherwise. But it just isn't guarranteed by the standard.
281. Illustration:
282. We have two thread IDs t1 and t2
283. pthread_t t1, t2;
284. In an application we create the threads and intend to store the thread IDs in an
285. ordered data structure (linked list, tree, etc) so we need to be able to compare
286. them in order to insert them initially and also to traverse.
287. Suppose pthread_t contains undefined padding bits and our compiler copies our
288. pthread_t [struct] element-by-element, then for the assignment:
289. pthread_t temp = t1;
290. temp and t1 will be equivalent and correct but a byte-for-byte comparison such as
291. memcmp(&temp, &t1, sizeof(pthread_t)) == 0 may not return true as we expect because
292. the undefined bits may not have the same values in the two variable instances.
293. Similarly if passing by value under the same conditions.
294. If, on the other hand, the undefined bits are at least constant through every
295. assignment and pass-by-value then the byte-for-byte comparison
296. memcmp(&temp, &t1, sizeof(pthread_t)) == 0 will always return the expected result.
297. How can we force the behaviour we need?
298. Solutions
299. Adding new functions to the standard API or as non-portable extentions is
300. the only reliable and portable way to provide the necessary operations.
301. Remember also that POSIX is not tied to the C language. The most common
302. functions that have been suggested are:
303. pthread_null()
304. pthread_compare()
305. pthread_hash()
306. A single more general purpose function could also be defined as a
307. basis for at least the last two of the above functions.
308. First we need to list the freedoms and constraints with restpect
309. to pthread_t so that we can be sure our solution is compatible with the
310. standard.
311. What is known or may be deduced from the standard:
312. 1) pthread_t must be able to be passed by value, so it must be a single object.
313. 2) from (1) it must be copyable so cannot embed thread-state information, locks
314. or other volatile objects required to manage the thread it associates with.
315. 3) pthread_t may carry additional information, e.g. for debugging or to manage
316. itself.
317. 4) there is an implicit requirement that the size of pthread_t is determinable
318. at compile-time and size-invariant, because it must be able to copy the object
319. (i.e. through assignment and pass-by-value). Such copies must be genuine
320. duplicates, not merely a copy of a pointer to a common instance such as
321. would be the case if pthread_t were defined as an array.
322. Suppose we define the following function:
323. /* This function shall return it's argument */
324. pthread_t* pthread_normalize(pthread_t* thread);
325. For scalar or aggregate pthread_t types this function would simply zero any bits
326. within the pthread_t that don't uniquely identify the thread, including padding,
327. such that client code can return consistent results from operations done on the
328. result. If the additional bits are a pointer to an associate structure then
329. this function would ensure that the memory used to store that associate
330. structure does not leak. After normalization the following compare would be
331. valid and repeatable:
332. memcmp(pthread_normalize(&t1),pthread_normalize(&t2),sizeof(pthread_t))
333. Note 1: such comparisons are intended merely to order and sort pthread_t values
334. and allow them to index various data structures. They are not intended to reveal
335. anything about the relationships between threads, like startup order.
336. Note 2: the normalized pthread_t is also a valid pthread_t that uniquely
337. identifies the same thread.
338. Advantages:
339. 1) In most existing implementations this function would reduce to a no-op that
340. emits no additional instructions, i.e after in-lining or optimisation, or if
341. defined as a macro:
342. #define pthread_normalise(tptr) (tptr)
343. 2) This single function allows an application to portably derive
344. application-level versions of any of the other required functions.
345. 3) It is a generic function that could enable unanticipated uses.
346. Disadvantages:
347. 1) Less efficient than dedicated compare or hash functions for implementations
348. that include significant extra non-id elements in pthread_t.
349. 2) Still need to be concerned about padding if copying normalized pthread_t.
350. See the later section on defining pthread_t to neutralise padding issues.
351. Generally a pthread_t may need to be normalized every time it is used,
352. which could have a significant impact. However, this is a design decision
353. for the implementor in a competitive environment. An implementation is free
354. to define a pthread_t in a way that minimises or eliminates padding or
355. renders this function a no-op.
356. Hazards:
357. 1) Pass-by-reference directly modifies 'thread' so the application must
358. synchronise access or ensure that the pointer refers to a copy. The alternative
359. of pass-by-value/return-by-value was considered but then this requires two copy
360. operations, disadvantaging implementations where this function is not a no-op
361. in terms of speed of execution. This function is intended to be used in high
362. frequency situations and needs to be efficient, or at least not unnecessarily
363. inefficient. The alternative also sits awkwardly with functions like memcmp.
364. 2) [Non-compliant] code that uses relational and equality operators on
365. arithmetic or pointer style pthread_t types would need to be rewritten, but it
366. should be rewritten anyway.
367. C implementation of null/compare/hash functions using pthread_normalize():
368. /* In pthread.h */
369. pthread_t* pthread_normalize(pthread_t* thread);
370. /* In user code */
371. /* User-level bitclear function - clear bits in loc corresponding to mask */
372. void* bitclear (void* loc, void* mask, size_t count);
373. typedef unsigned int hash_t;
374. /* User-level hash function */
375. hash_t hash(void* ptr, size_t count);
376. /*
377. * User-level pthr_null function - modifies the origin thread handle.
378. * The concept of a null pthread_t is highly implementation dependent
379. * and this design may be far from the mark. For example, in an
380. * implementation "null" may mean setting a special value inside one
381. * element of pthread_t to mean "INVALID". However, if that value was zero and
382. * formed part of the id component then we may get away with this design.
383. */
384. pthread_t* pthr_null(pthread_t* tp)
385. {
386. /*
387. * This should have the same effect as memset(tp, 0, sizeof(pthread_t))
388. * We're just showing that we can do it.
389. */
390. void* p = (void*) pthread_normalize(tp);
391. return (pthread_t*) bitclear(p, p, sizeof(pthread_t));
392. }
393. /*
394. * Safe user-level pthr_compare function - modifies temporary thread handle copies
395. */
396. int pthr_compare_safe(pthread_t thread1, pthread_t thread2)
397. {
398. return memcmp(pthread_normalize(&thread1), pthread_normalize(&thread2), sizeof(pthread_t));
399. }
400. /*
401. * Fast user-level pthr_compare function - modifies origin thread handles
402. */
403. int pthr_compare_fast(pthread_t* thread1, pthread_t* thread2)
404. {
405. return memcmp(pthread_normalize(&thread1), pthread_normalize(&thread2), sizeof(pthread_t));
406. }
407. /*
408. * Safe user-level pthr_hash function - modifies temporary thread handle copy
409. */
410. hash_t pthr_hash_safe(pthread_t thread)
411. {
412. return hash((void *) pthread_normalize(&thread), sizeof(pthread_t));
413. }
414. /*
415. * Fast user-level pthr_hash function - modifies origin thread handle
416. */
417. hash_t pthr_hash_fast(pthread_t thread)
418. {
419. return hash((void *) pthread_normalize(&thread), sizeof(pthread_t));
420. }
421. /* User-level bitclear function - modifies the origin array */
422. void* bitclear(void* loc, void* mask, size_t count)
423. {
424. int i;
425. for (i=0; i < count; i++) {
426. (unsigned char) *loc++ &= ~((unsigned char) *mask++);
427. }
428. }
429. /* Donald Knuth hash */
430. hash_t hash(void* str, size_t count)
431. {
432. hash_t hash = (hash_t) count;
433. unsigned int i = 0;
434. for(i = 0; i < len; str++, i++)
435. {
436. hash = ((hash << 5) ^ (hash >> 27)) ^ (*str);
437. }
438. return hash;
439. }
440. /* Example of advantage point (3) - split a thread handle into its id and non-id values */
441. pthread_t id = thread, non-id = thread;
442. bitclear((void*) &non-id, (void*) pthread_normalize(&id), sizeof(pthread_t));
443. A pthread_t type change proposal to neutralise the effects of padding
444. Even if pthread_nornalize() is available, padding is still a problem because
445. the standard only garrantees element-by-element equivalence through
446. copy operations (assignment and pass-by-value). So padding bit values can
447. still change randomly after calls to pthread_normalize().
448. [I suspect that most compilers take the easy path and always byte-copy anyway,
449. partly because it becomes too complex to do (e.g. unions that contain sub-aggregates)
450. but also because programmers can easily design their aggregates to minimise and
451. often eliminate padding].
452. How can we eliminate the problem of padding bytes in structs? Could
453. defining pthread_t as a union rather than a struct provide a solution?
454. In fact, the Linux pthread.h defines most of it's pthread_*_t objects (but not
455. pthread_t itself) as unions, possibly for this and/or other reasons. We'll
456. borrow some element naming from there but the ideas themselves are well known
457. - the __align element used to force alignment of the union comes from K&R's
458. storage allocator example.
459. /* Essentially our current pthread_t renamed */
460. typedef struct {
461. struct thread_state_t * __p;
462. long __x; /* sequence counter */
463. } thread_id_t;
464. Ensuring that the last element in the above struct is a long ensures that the
465. overall struct size is a multiple of sizeof(long), so there should be no trailing
466. padding in this struct or the union we define below.
467. (Later we'll see that we can handle internal but not trailing padding.)
468. /* New pthread_t */
469. typedef union {
470. char __size[sizeof(thread_id_t)]; /* array as the first element */
471. thread_id_t __tid;
472. long __align;  /* Ensure that the union starts on long boundary */
473. } pthread_t;
474. This guarrantees that, during an assignment or pass-by-value, the compiler copies
475. every byte in our thread_id_t because the compiler guarrantees that the __size
476. array, which we have ensured is the equal-largest element in the union, retains
477. equivalence.
478. This means that pthread_t values stored, assigned and passed by value will at least
479. carry the value of any undefined padding bytes along and therefore ensure that
480. those values remain consistent. Our comparisons will return consistent results and
481. our hashes of [zero initialised] pthread_t values will also return consistent
482. results.
483. We have also removed the need for a pthread_null() function; we can initialise
484. at declaration time or easily create our own const pthread_t to use in assignments
485. later:
486. const pthread_t null_tid = {0}; /* braces are required */
487. pthread_t t;
488. ...
489. t = null_tid;
490. Note that we don't have to explicitly make use of the __size array at all. It's
491. there just to force the compiler behaviour we want.
492. Partial solutions without a pthread_normalize function
493. An application-level pthread_null and pthread_compare proposal
494. (and pthread_hash proposal by extention)
495. In order to deal with the problem of scalar/aggregate pthread_t type disparity in
496. portable code I suggest using an old-fashioned union, e.g.:
497. Contraints:
498. - there is no padding, or padding values are preserved through assignment and
499. pass-by-value (see above);
500. - there are no extra non-id values in the pthread_t.
501. Example 1: A null initialiser for pthread_t variables...
502. typedef union {
503. unsigned char b[sizeof(pthread_t)];
504. pthread_t t;
505. } init_t;
506. const init_t initial = {0};
507. pthread_t tid = initial.t; /* init tid to all zeroes */
508. Example 2: A comparison function for pthread_t values
509. typedef union {
510. unsigned char b[sizeof(pthread_t)];
511. pthread_t t;
512. } pthcmp_t;
513. int pthcmp(pthread_t left, pthread_t right)
514. {
515. /*
516. * Compare two pthread handles in a way that imposes a repeatable but arbitrary
517. * ordering on them.
518. * I.e. given the same set of pthread_t handles the ordering should be the same
519. * each time but the order has no particular meaning other than that. E.g.
520. * the ordering does not imply the thread start sequence, or any other
521. * relationship between threads.
522. *
523. * Return values are:
524. * 1 : left is greater than right
525. * 0 : left is equal to right
526. * -1 : left is less than right
527. */
528. int i;
529. pthcmp_t L, R;
530. L.t = left;
531. R.t = right;
532. for (i = 0; i < sizeof(pthread_t); i++)
533. {
534. if (L.b[i] > R.b[i])
535. return 1;
536. else if (L.b[i] < R.b[i])
537. return -1;
538. }
539. return 0;
540. }
541. It has been pointed out that the C99 standard allows for the possibility that
542. integer types also may include padding bits, which could invalidate the above
543. method. This addition to C99 was specifically included after it was pointed
544. out that there was one, presumably not particularly well known, architecture
545. that included a padding bit in it's 32 bit integer type. See section 6.2.6.2
546. of both the standard and the rationale, specifically the paragraph starting at
547. line 16 on page 43 of the rationale.
548. An aside
549. Certain compilers, e.g. gcc and one of the IBM compilers, include a feature
550. extention: provided the union contains a member of the same type as the
551. object then the object may be cast to the union itself.
552. We could use this feature to speed up the pthrcmp() function from example 2
553. above by casting rather than assigning the pthread_t arguments to the union, e.g.:
554. int pthcmp(pthread_t left, pthread_t right)
555. {
556. /*
557. * Compare two pthread handles in a way that imposes a repeatable but arbitrary
558. * ordering on them.
559. * I.e. given the same set of pthread_t handles the ordering should be the same
560. * each time but the order has no particular meaning other than that. E.g.
561. * the ordering does not imply the thread start sequence, or any other
562. * relationship between threads.
563. *
564. * Return values are:
565. * 1 : left is greater than right
566. * 0 : left is equal to right
567. * -1 : left is less than right
568. */
569. int i;
570. for (i = 0; i < sizeof(pthread_t); i++)
571. {
572. if (((pthcmp_t)left).b[i] > ((pthcmp_t)right).b[i])
573. return 1;
574. else if (((pthcmp_t)left).b[i] < ((pthcmp_t)right).b[i])
575. return -1;
576. }
577. return 0;
578. }
579. Result thus far
580. We can't remove undefined bits if they are there in pthread_t already, but we have
581. attempted to render them inert for comparison and hashing functions by making them
582. consistent through assignment, copy and pass-by-value.
583. Note: Hashing pthread_t values requires that all pthread_t variables be initialised
584. to the same value (usually all zeros) before being assigned a proper thread ID, i.e.
585. to ensure that any padding bits are zero, or at least the same value for all
586. pthread_t. Since all pthread_t values are generated by the library in the first
587. instance this need not be an application-level operation.
588. Conclusion
589. I've attempted to resolve the multiple issues of type opacity and the possible
590. presence of undefined bits and bytes in pthread_t values, which prevent
591. applications from comparing or hashing pthread handles.
592. Two complimentary partial solutions have been proposed, one an application-level
593. scheme to handle both scalar and aggregate pthread_t types equally, plus a
594. definition of pthread_t itself that neutralises padding bits and bytes by
595. coercing semantics out of the compiler to eliminate variations in the values of
596. padding bits.
597. I have not provided any solution to the problem of handling extra values embedded
598. in pthread_t, e.g. debugging or trap information that an implementation is entitled
599. to include. Therefore none of this replaces the portability and flexibility of API
600. functions but what functions are needed? The threads standard is unlikely to
601. include that can be implemented by a combination of existing features and more
602. generic functions (several references in the threads rationale suggest this.
603. Therefore I propose that the following function could replace the several functions
604. that have been suggested in conversations:
605. pthread_t * pthread_normalize(pthread_t * handle);
606. For most existing pthreads implementations this function, or macro, would reduce to
607. a no-op with zero call overhead.

4 QueueUserAPCEx编译

由于VS2013 + WDK 8.1 Update编译驱动的方式我还没有搞清楚，以后补上。

5 pthread通用初始化头文件

对于pthread_win32的使用我提供一个通用的初始化文件“cruise_ptw32_static_init.h”，如下

[cpp] view plaincopy

print?

1. #ifndef CRUISE_PTW32_STATIC_INIT_H
2. #define CRUISE_PTW32_STATIC_INIT_H
3. #ifdef PTW32_STATIC_LIB
4. #include <cstdlib>
5. #include <pthread.h>
6. #endif
7. staticvoidptw32_enable_cancel(void)
8. {
9. #ifdef PTW32_STATIC_LIB
10. pthread_setcancelstate(PTHREAD_CANCEL_ENABLE, NULL);
11. pthread_setcanceltype(PTHREAD_CANCEL_ASYNCHRONOUS, NULL);
12. #endif
13. }
14. #define CRUISE_PTW32_ENABLE_CANCEL()    {ptw32_enable_cancel();}
15. staticvoidptw32_attach(void)
16. {
17. #ifdef PTW32_STATIC_LIB
18. pthread_win32_process_attach_np();
19. pthread_win32_thread_attach_np();
20. #endif
21. }
22. staticvoidptw32_detach(void)
23. {
24. #ifdef PTW32_STATIC_LIB
25. pthread_win32_thread_detach_np();
26. pthread_win32_process_detach_np();
27. #endif
28. }
29. #if defined(_WIN32) && defined(PTW32_STATIC_LIB)
30. #define CRUISE_PTW32_INIT()                                     \
31. {                                                               \
32. attach_ptw32();                                             \
33. atexit((P_ATEXIT_PROC)detach_ptw32);                        \
34. }
35. #else
36. #define CRUISE_PTW32_INIT()
37. #endif
38. #endif // CRUISE_PTW32_STATIC_INIT_H

6 参考资料

pthread学习
http://www.cppblog.com/saha/articles/189802.html
pthread_win32下的 pthread_t与posix的pthread_t的不同
http://www.cnblogs.com/ayanmw/archive/2012/08/07/2626661.html
pthread 静态编译版本在Windows下使用时的注意事项
http://blog.csdn.net/psusong/article/details/5189659
64位win7 vs2010 pthread的配置 - - ITeye技术网站
http://houyingsoft.iteye.com/blog/1907670
跨平台多线程
http://shenan1984.blog.163.com/blog/static/2530851020098231001787/
QueueUserAPCEx版本2:真正的异步通知用户模式在Windows平台上
http://www.orcode.com/article/Processes_20117249.html
跨平台多线程编程-fychit-ChinaUnix博客
http://blog.chinaunix.net/uid-20776117-id-1847029.html
跨平台多线程库pthread
http://blog.csdn.net/yinyhy/article/details/10959997
pthread-win32静态库的编译和使用方法
http://download.csdn.net/detail/eugenelyq/3604896
/MinGW/Base/pthreads-w32/pthreads-w32-2.9.0-pre-20110507-2
http://sourceforge.net/projects/mingw/files/MinGW/Base/pthreads-w32/pthreads-w32-2.9.0-pre-20110507-2/