C/C++ 是否存在线程问题？ “系统级程序员” 与 Java 程序员面临的情况有很大不同吗？
我正在寻找一份开发工作，发现许多清单都指定开发人员必须精通多线程。 对于 Java 职位列表和涉及 UNIX 上“系统编程”的 C++ 职位列表都会出现这种情况。
在过去的几年里，我一直在使用 Java 并使用它的各种同步机制。
在 90 年代末，我做了很多 C++ 工作，但线程很少。 然而，在大学里，我们在 Solaris 上使用线程。
我的问题是，与 Java 开发人员相比，C/C++ 开发人员面临的问题是否存在显着差异，以及解决这些问题的技术是否有根本不同。 Java 显然包含一些更好的机制和集合的同步版本等。
如果我想刷新或重新学习 UNIX 上的线程，最好的方法是什么？ 我应该看哪个图书馆？ 等等。目前有一些关于 C++ 线程的很棒的教程吗？
I'm looking for a development job and see that many listings specify that the developers must be versed in multithreading. This appears both for Java job listings, and for C++ listings that involve "system programming" on UNIX.
In the past few years I have been working with Java and using its various synchronization mechanisms.
In the late 90s I did a lot of C++ work, though very little threads. In college, however, we used threads on Solaris.
My question is whether there are significant differences in the issues that developers in C/C++ face compared to developers in Java, and whether any of the techniques to address them are fundamentally different. Java obviously includes some nicer mechanisms and synchronized versions of collections, etc.
If I want to refresh or relearn threading on UNIX, what's the best approach? Which library should I look at? etc. Is there some great current tutorial on threads in c++?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（6）
线程的基本挑战（例如同步、竞争条件、线程间通信、资源清理），但 Java 通过垃圾收集、异常、高级同步对象、带有反射的高级调试支持使线程更易于管理。
使用 C++，您更有可能出现内存损坏和“不可能的”竞争条件。 您将需要编写更多低级线程原语或依赖不属于标准化语言的库（如 boost）。
The fundamental challenges of threading (e.g. synchronization, race conditions, inter-thread communication, resource cleanup), but Java makes thread much more manageable with garbage collection, exceptions, advanced synchronization objects, advanced debugging support with reflection.
With C++, you are much more likely to have memory corruption and "impossible" race conditions. And you will need to write a lot more low-level thread primitives or rely on libraries (like boost) that are not part of the standardized language.
C++ 实际上比 Java 更容易编写复杂的线程代码，因为它具有 Java 所缺乏的功能 - RAII 或“资源获取即初始化”。 此习惯用法用于编写良好的 C++ 代码中的所有资源控制，但特别适用于必须自动管理同步的多线程代码。
C++ is actually aeasier to write complex threaded code in than Java because it has a feature Java lacks - RAII or "resource acquisition is initialisation". This idiom is used for all all resource control in well written C++ code, but is particularly appropriate in multi-threaded code where automatic management of synchronisation is a must.
查看 pthreads 和 boost （pthreads 是一个随机的lijnk，但作为起点看起来还不错）。
从高层次来看，Java/C/C++/ 的问题是相同的。 关于如何解决问题的具体细节（调用的函数、创建的类等）因语言而异。
Look at pthreads and boost (the pthreads one was a random lijnk, but it looks ok as a starting point).
At a high level the issues for Java/C/C++/ are the same. The specifics about how you solve the problem (functions to call, classes to create, etc...) vary language to language.
垃圾收集使不泄漏内存的线程编程变得更容易，并且有花哨的东西 您可以解决收集的时间问题。
确定性析构函数使不会产生僵尸的编程线程变得更容易，请参阅此处的 ACM 论文
Garbage collection makes programming threads that do not leak memory easier, and there are fancy things you can do to address the timing of the collections.
Deterministic destructors make programming threads that do not spawn zombies easier, see ACM paper here
这取决于您选择在什么级别工作。 英特尔 TBB 和 OpenMP 从相当高的水平处理许多常见情况。 Posix 线程、Windows API 和可移植库（如 Boost 线程）使您更接近 Java 中原语的水平。
C++0x 线程（特别是具有获取和释放内存屏障）允许您进入比 Java 提供的更低级别的更多控制和复杂性（在 Java 中标记变量
易失性使其既可以获取又可以获取内存）和释放内存屏障，但在 Java 中你不能只要求获取或释放屏障；而在 C++0x 中则可以）。请注意，C++0x 的线程模型故意设置为低级别，希望人们能够在其之上构建 TBB 之类的东西，并且下次标准委员会开会时，他们将能够找出哪些更高级别的库和工具包工作得很好，值得学习。
It depends on what level you choose to work at. Intel TBB and OpenMP handle a lot of common cases from a pretty high level. Posix threads, Windows APIs, and portable libraries like Boost threads bring you closer to the same level as primitives in Java.
C++0x threading (especially with acquire and release memory barriers) allow you to go to an even lower level for more control and complexity than Java offers (marking a variable
volatilein Java gives it both an acquire and a release memory barrier, but in Java you can't ask for just the acquire or just the release barrier; where in C++0x you can).Please note that C++0x's threading model is intentionally low level with the hope that people will build things like TBB on top of it and the next time the standards committee meets they'll be able to figure out which of those higher level libraries and toolkits work well enough to learn from.
无论使用哪种编程语言，线程的特性都是常见的。 例如，即使跨操作系统，POSIX 线程和线程也是如此。 WIN32 线程具有相同的逻辑特性集，尽管 API 调用 & 本机实现 WRT 底层硬件/内核可能会发生变化，但对于系统程序员来说，关于线程和线程的逻辑思维可能会改变。 如何使它们按预期工作& 实现这一目标是最困难的部分。 对于编程语言来说更是如此。 如果你真正理解线程和线程的概念 线程同步你很高兴去＆amp; 在您喜欢的任何编程语言中使用它们。 由于这些编程语言在本机线程/线程同步实现之上提供了语法糖。
Regardless of the programming language being uses, the idiosyncrasy of thread are common. For instance even across OS the POSIX threads & WIN32 threads have same set of logical idiosyncrasies, though the API calls & native implementation WRT underlying hardware/kernel might change, but to system programmers the logical thinking about threads & how to make them work as expected & in achieving this is the most hardest part. This is even true when coming to programming languages. If you really understand the concept of threading & thread synchronization you are good to go & use them in any programming languages you like. Since these programming languages provide syntactic sugars on top of the native thread/thread synchronization implementation.