线程在新的C ++标准中 [英] Threading in new C++ standard
问题描述
而不是创造一种新的做事方式：
http://www.open-std.org/jtc1/sc22/wg...008/n2497.html
为什么不呢只需将ACE纳入现有标准：
http： //www.cse.wustl.edu/~schmidt/ACE.html
与STL（以及随后的BOOST）相同的方式包含在内？
因为它已经在数以万计的平台上运行，所以它们显然已经在广义线程和流程概念中解决了大部分问题（沿着
以及许多其他有用的抽象） 。
比通用线程更有趣的是概括的
软件交易。英特尔编译器有一个实验版本
这样做：
http://softwarecommunity.intel.com/a...s/eng/1460.htm
随着我们扩展到更大的更多的CPU，软件交易
模型是获得牵引力的模型。这个文件在
中非常有说服力：
http://internap.dl.sourceforge.net/s..._submitted.pdf
**发自 http://www.teranews.com **
Rather than create a new way of doing things:
http://www.open-std.org/jtc1/sc22/wg...008/n2497.html
why not just pick up ACE into the existing standard:
http://www.cse.wustl.edu/~schmidt/ACE.html
the same way that the STL (and subsequently BOOST) have been subsumed?
Since it already runs on zillions of platforms, they have obviously worked
most of the kinks out of the generalized threading and processes idea (along
with many other useful abstractions).
Even more interesting than generalized threading would be generalized
software transactions. The Intel compiler has an experimental version that
does this:
http://softwarecommunity.intel.com/a...s/eng/1460.htm
As we scale to larger and larger numbers of CPUs, the software transaction
model is the one that gains traction. This document is very illuminating in
that regard:
http://internap.dl.sourceforge.net/s..._submitted.pdf
** Posted from http://www.teranews.com **
推荐答案
Dann Corbit写道：
Dann Corbit wrote:
而不是创造一种新的做事方式：
http：//www.open-std。 org / jtc1 / sc22 / wg ... 008 / n2497.html
为什么不把ACE纳入现有标准：
http://www.cse.wustl.edu/~schmidt/ACE.html
与STL（以及随后的BOOST）已经存在的方式相同ed？
因为它已经在数以万计的平台上运行，所以它们显然已经在广义线程和流程概念中解决了大部分问题（沿着
与许多其他有用的抽象）。
Rather than create a new way of doing things:
http://www.open-std.org/jtc1/sc22/wg...008/n2497.html
why not just pick up ACE into the existing standard:
http://www.cse.wustl.edu/~schmidt/ACE.html
the same way that the STL (and subsequently BOOST) have been subsumed?
Since it already runs on zillions of platforms, they have obviously worked
most of the kinks out of the generalized threading and processes idea (along
with many other useful abstractions).
这不是一种新方式。它来自提升。
点击链接n2497，向下滚动并阅读：
"致谢
这个线程库的整体设计基于William Kempf的
Boost.Thread库，由数百名其他Boost用户改进
和贡献者。 ;
-
托马斯
http://www.netmeister.org/news/learn2quote.html
有些人是明智的，有些则是明智的。
It''s not a new way. Its from boost.
Click on the Link for n2497, scroll down and read:
"Acknowledgments
The overall design of this threading library is based on William Kempf''s
Boost.Thread Library, as refined by literally hundreds of other Boost users
and contributors."
--
Thomas
http://www.netmeister.org/news/learn2quote.html
"Some folks are wise, and some otherwise."
Dann Corbit写道：
Dann Corbit writes:
而不是创造一种新的做事方式：
< a rel =nofollowhref =http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2008/n2497.html\"target =_ blank> http://www.open -std.org/jtc1/sc22/wg...008/n2497.html
为什么不把ACE纳入现有标准：
http://www.cse.wustl.edu/~schmidt/ACE.html
也许是因为不是每个人都分享你对ACE的热情？
Perhaps because not everyone shares your enthusiasm for ACE?
和STL（以及随后的BOOST）一样纳入？
the same way that the STL (and subsequently BOOST) have been subsumed?
Boost也不是普遍喜欢的。俗话说：只是因为
每个人都决定跳下悬崖，你应该跟着吗？
----- BEGIN PGP SIGNATURE --- -
版本：GnuPG v1.4.7（GNU / Linux）
iD8DBQBIBTuRx9p3GYHlUOIRAs8pAJ4mbo / nlrRALBXE17a1LAY0Yz8VIQCfX8Zu
wpfbinv1 / + hc7LVtnDL9zsA =
= WbVf
----- END PGP SIGNATURE -----
Boost is not universally liked either. As the saying goes: just because
everyone decides to jump off a cliff, should you follow?
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.7 (GNU/Linux)
iD8DBQBIBTuRx9p3GYHlUOIRAs8pAJ4mbo/nlrRALBXE17a1LAY0Yz8VIQCfX8Zu
wpfbinv1/+hc7LVtnDL9zsA=
=WbVf
-----END PGP SIGNATURE-----
On 4月16日上午12:28，Dann Corbit < dcor ... @ connx.comwrote：
On Apr 16, 12:28 am, "Dann Corbit" <dcor...@connx.comwrote:
而不是创建一种新的做事方式： http://www.open-std.org/jtc1/sc22/wg .. .008 / n2497.html
为什么不把ACE纳入现有的
标准： http://www.cse.wustl.edu/~schmidt/ACE.html 同样
STL（以及随后的BOOST）被包含的方式？
Rather than create a new way of doing things:http://www.open-std.org/jtc1/sc22/wg...008/n2497.html
why not just pick up ACE into the existing
standard:http://www.cse.wustl.edu/~schmidt/ACE.html the same
way that the STL (and subsequently BOOST) have been subsumed?
ACE使用的模型存在严重问题。
There are serious problems with the model ACE uses.
因为它已经在数以万计的平台上运行，他们有
显然在广义的
线程和处理想法（以及许多其他有用的
抽象）中解决了大部分问题。
Since it already runs on zillions of platforms, they have
obviously worked most of the kinks out of the generalized
threading and processes idea (along with many other useful
abstractions).
它实际上并没有在数以亿计的平台上使用---据我知道，它支持Windows和Unix，这就是它。
ACE有点过时，并使用什么是当时的经典模型？b
线程对象已开发。今天一般的
一致意见是这个模型并不是真的那么适合，至少对于一个有价值语义的语言来说，比如
C ++ 。
第二个方面是ACE（和Boost，它代表了一个更多最先进的模型模型）只能解决其中一个原因
需要
线程，并且不能有效地支持
并行化等用途，这对于多核机器的扩散来说变得非常重要。
It''s not actually used on "zillions of platforms"---as far as I
know, it supports Windows and Unix, and that''s about it.
ACE is somewhat dated, and uses what was the classical model for
thread objects at the time it was developed. The general
concensus today is that this model isn''t really that
appropriate, at least for a language with value semantics like
C++.
The second aspect is that ACE (and Boost, which represents a
more "state of the art" model) only address one of the reasons
threading is desired, and don''t effectively support uses like
parallelizing, which are becoming important with the diffusion
of multicore machines.
比一般化线程更有趣的是广义软件交易。英特尔编译器有一个
的实验版本，这个版本是这样的： http://softwarecommunity.intel.com/a...s/eng/1460.htm
我想当我们知道支持线程的最佳成语时，我们仍然在很大程度上处于起步阶段。而不是
标准化实验的东西，后来证明是远远不理想的b $ b，我认为我们应该只标准化
必要的最低限度人们可以建立和实验。
-
James Kanze（GABI软件）电子邮件：ja ********* @ gmail.com
Conseils eninformatiqueorientéeobjet/
Beratung in objektorientierter Datenverarbeitung
9placeSémard，78210 St.-Cyr-l'' école，法国，+ 33（0）1 30 23 00 34
I think we''re still largely at the beginning when it comes to
knowing the best idioms to support threading. Rather than
standardize something experimental, which later turns out to be
far less than ideal, I think we should only standardize an
essential minimum, on which people can build and experiment.
--
James Kanze (GABI Software) email:ja*********@gmail.com
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
9 place Sémard, 78210 St.-Cyr-l''école, France, +33 (0)1 30 23 00 34
这篇关于线程在新的C ++标准中的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
