Visual C 中的 Pthreads
我正在 Windows 中尝试多线程，想知道是否应该
如果我学习 Pthreads 将会很有用尝试在不同平台上开发此类应用程序 - 但如果不学习 Win32 API，我会失去什么吗？或者两者足够相似，以至于学习其中一个可以让我轻松地找出另一个？
I'm experimenting with multithreading in Windows and was wondering whether I should
Learning Pthreads would be useful if I tried to develop such applications on different platforms - but am I losing anything by not learning Win32 API? Or are both similar enough so that learning one allows me to figure out the other easily?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（5）
使用增强线程。当 C++0x 出现时，我们将拥有 std::threads。 Boost 线程具有与 std 线程最接近的实现。
否则使用 pthreads。 Pthreads 与 std::threads 第二接近，并且形成了 std 线程和 boost 线程的主要基础。
否则直接进行 Windows 线程处理。您仍然可以了解线程如何工作，并形成事物的心理模型。它只是倾向于使用有点不标准的同步原语。
Use Boost Threads. When C++0x comes along, we will have std::threads. Boost threads has the closest implementation to std threads.
else use pthreads. Pthreads is second closest to std::threads, and formed the main basis of std threads and boost threads.
else do windows threading directly. You can still learn how threads work, and form a mental model of things. It just tends to use synchronization primitives that are a bit non-standard.
如果您要进行大量 Windows 编程，那么学习基本的 Win32 线程结构是值得的：临界区、互锁函数、CreateThread、WaitFor*Object 等。这些并不难理解，并且它们可以透明地转换为其他线程框架中的等效对象。
但是，对于更高级的线程结构（例如信号量、事件等），我会使用 pthreads 库，因为有关这些结构的文档往往更清晰，示例也更丰富。
If you're going to do much Windows programming, it will pay to learn the basic Win32 threading constructs: critical sections, interlocked functions,
CreateThread,WaitFor*Object, etc. These aren't hard to understand, and they translate transparently to equivalent objects in other threading frameworks.However, for more advanced threading constructs such as semaphores, events, etc., I would use the
pthreadslibrary, since the documentation on those tends to be clearer and examples more abundant.如果您使用的是 C/C++，请尝试使用 C/C++ 运行时的线程函数。
如果您使用 Win32（或其他非 CRT 函数来创建线程），CRT 可能无法在新线程中正确初始化，从而导致各种问题（您可以在此处阅读相关内容：http://www.codeguru.com/forum/archive/index.php/t-371305.html ）。
然而，大多数线程函数（在 CRT、Win32 或 pthread 中）都是基于创建线程、同步线程和销毁线程的功能。实际上，这并不总是那么容易使用。
去年，有一种趋势是转向基于任务的线程（好吧，我就是这么称呼它的，我不知道正式名称是什么）。在基于任务的线程中，您不是启动一个线程然后在其中执行一些逻辑，而是创建一个任务，然后要求“线程逻辑”执行该任务。
支持这种新的线程处理方式的系统有：
Visual Studio 2010 甚至有（看起来）特殊的调试逻辑来调试“并行任务” '。
If you're using C/C++, try to use the thread functions of the C/C++ runtime.
If you use the Win32 (or other non-CRT functions to create threads) the CRT might not be initialized correctly in the new thread, causing all kinds of problem (you can read about it here: http://www.codeguru.com/forum/archive/index.php/t-371305.html).
However, most thread-functions (in the CRT, Win32 or pthread) are all based around the functionality to create threads, synchronize threads and destroy threads. In practice this isn't always that easy to use.
In the last year, there is a trend to go to task-based threading (well, I call it that way, I don't know what the official name is). Instead of starting a thread and then executing some logic in it, in task-based threading you create a task and then ask the 'threading logic' to execute the task.
Systems that support this new way of working with threads are:
Visual Studio 2010 even has (it seems) special debugging logic to debug the 'parallel tasks'.
看一下 std::thread
http: //www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2184.html
以及简介
http://www.devx.com/SpecialReports/Article/38883
Take a look at std::thread
http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2184.html
And a introduction
http://www.devx.com/SpecialReports/Article/38883
我发现坚持使用 pthreads 在三个方面可以让我保持理智：
WinAPI 文档，不习惯使用
任何品质的。
可以帮忙
线程。我在网上找到了无数关于 pthreads 的好信息来源。
复杂的是“Hello World”
WinAPI，我发现它需要很长时间
比合理的时间长
预计。这只是我的经验
不过，输入。
就功能而言，我从未发现 pthreads 缺乏任何东西，因此我认为我没有必要去其他地方寻找。学习一个可以在您处理的任何环境中使用的库也有很多值得说的。
I've found that sticking with pthreads saves my sanity on three counts:
WinAPI docs, which aren't habitually
of any quality.
can help out with
pthreads. I've found infinitely more good sources of information about pthreads online.
complicated that "Hello World" with
the WinAPI, I find it takes far
longer than one could reasonably
expect. That's just my empirical
input, though.
As far as capabilities are concerned, I've never found pthreads to be lacking in anything, so I don't think I've ever found the need to look elsewhere. There is also a great deal to be said for learning a library that you'll be able to use in any environment you tackle.