多线程C编程（适合那些喜欢移植的人） [英] Multi-threaded C programming (for those fond of portability)
问题描述
据我所知，C标准没有提到多线程
编程;它没有提到如何实现多线程
编程，也没有提到语言或它的库是否适合多线程编程。
对于喜欢便携式C编程的人来说，多线程编程的最佳方式是什么？
$ b / b
我一直在阅读POSIX线程，它们看起来很漂亮
无处不在。这是最好的方式吗？
我看到的一个问题是关于线程安全的问题。标准C库中的函数
。假设在实现POSIX线程的系统上，标准C库将是否是线程安全的？b $ b是否公平？或者是否有一种众所周知的方式要求编译器确保这一点，例如通过定义预处理器指令
_REENTRANT？
我基本上都在寻找最便携的方式编写一个
多线程应用程序。
< blockquote>Tomásóhéilidhe< to*@lavabit.comwrites：
对于喜欢便携式C编程的人来说，最好的方法是什么？ >
进行多线程编程？
你有一套合理的问题，但这不是一个好的
的地方问他们。如果你在comp.programming.threads，
中问他们，你可能会得到更好的答案。
-
给我几年和一个大型研究基金，
，我会给你一张收据。 - 理查德希思菲尔德
文章< cb ************************** ******** @ v39g2000pro。 googlegroups.com>，
Tomas S hIilidhe< to *@lavabit.comwrote：
>对于喜欢便携的人C编程，进行多线程编程的最佳方法是什么？
选择一个合理广泛实施的标准，定义一个线程
接口，写入该标准，然后将其声明为Portable to
支持C +< other standard>"的平台。
>我一直在阅读POSIX线程有点，看起来很漂亮无处不在。这会是最好的方式吗？
我没资格评论最佳，但它可能是一个相当不错的
方式。 br />
>我所看到的一个问题是关于线程安全的问题。标准C库中的函数
。假设在实现POSIX线程的系统上，标准C库是否是线程安全的，这是否公平？或者有一种众所周知的方式要求编译器确保这一点，例如通过定义预处理器指令
_REENTRANT？
我会假设任何敏感线程规范的一部分
API是与
多线程程序（需要支持的实现，
以及程序员禁止做什么）。
对于POSIX，comp .unix.programmer可能是一个讨论这个东西的好地方。
dave
-
Dave Vandervies dj3vande在eskimo dot com
但我并不想成为一名[护理人员]，因为我的潜意识知道
学会独立飞行比我的能力更可能是
a护理人员。 --David Cameron Staples在可怕的魔鬼修道院中
Tomásóhéilidhe写道：
对于那些人来说喜欢便携式C编程，多线程编程的最佳方式是什么？
我一直在阅读POSIX线程，它们看起来很漂亮
无处不在。这会是最好的方式吗？
我想是那个或OpenMP。但正如Ben所说，转到comp.programming.threads。
我看到的一个问题是关于线程安全的问题。标准C库中的函数
。假设在实现POSIX线程的系统上，标准C库将是否是线程安全的？b $ b是否公平？或者是否有一种众所周知的方式要求编译器确保这一点，例如通过定义预处理器指令
_REENTRANT？
_REENTRANT在编译器的命名空间中，所以不要触摸它，除非
编译器文档或它遵循的某个标准说你应该。有
将是一些编译器选项，使编译器生成线程安全的
目标代码，链接正确的库，＃define类似
_REENTRANT你可以#ifdef on等。请参阅编译器的文档
的那个开关，不要因为它似乎工作而尝试一些东西。
-
Hallvard
As far as I know, the C Standard has no mention of multi-threaded
programming; it has no mention of how to achieve multi-threaded
programming, nor does it mention whether the language or its libraries
are suitable for multi-threaded programming.
For people who are fond of portable C programming, what''s the best way
to go about multi-threaded programming?
I''ve been reading up on POSIX threads a little, they seem pretty
ubiquitous. Would this be the best way to go?
One issue I''ve seen raised is about the "thread safety" of functions
in the Standard C library. Would it be fair to assume, on systems
where POSIX threads is implemented, that the Standard C library will
be thread-safe? Or is there a well-known way of asking the compiler to
ensure this, for example by defining the preprocessor directive
_REENTRANT?
I''m basically looking for the most portable way possible to write a
multi-threaded application.
Tomás ó héilidhe <to*@lavabit.comwrites:
For people who are fond of portable C programming, what''s the best way
to go about multi-threaded programming?You have a set of reasonable questions, but this is not a good
place to ask them. If you ask them in comp.programming.threads,
instead, you are likely to receive better answers.
--
"Give me a couple of years and a large research grant,
and I''ll give you a receipt." --Richard Heathfield
In article <cb**********************************@v39g2000pro. googlegroups.com>,
Tomas S hIilidhe <to*@lavabit.comwrote:
>For people who are fond of portable C programming, what''s the best way
to go about multi-threaded programming?Pick a reasonably widely implemented standard that defines a threading
interface, write to that standard, and declare it "Portable to
platforms that support C + <other standard>".
>I''ve been reading up on POSIX threads a little, they seem pretty
ubiquitous. Would this be the best way to go?I''m not qualified to comment on "best", but it''s probably a rather good
way.
>One issue I''ve seen raised is about the "thread safety" of functions
in the Standard C library. Would it be fair to assume, on systems
where POSIX threads is implemented, that the Standard C library will
be thread-safe? Or is there a well-known way of asking the compiler to
ensure this, for example by defining the preprocessor directive
_REENTRANT?I would assume that part of the specification of any sensible threading
API is additional requirements on the C standard library related to
multithreaded programs (what the implementation is required to support,
and what the programmer is forbidden from doing).
For POSIX, comp.unix.programmer is probably a good place to ask about
such things.
dave
--
Dave Vandervies dj3vande at eskimo dot com
But I don''t daydream about being a [paramedic], because my subconscious knows
that learning to fly unassisted is more likely than my being capable of being
a paramedic. --David Cameron Staples in the scary devil monastery
Tomás ó héilidhe writes:For people who are fond of portable C programming, what''s the best way
to go about multi-threaded programming?
I''ve been reading up on POSIX threads a little, they seem pretty
ubiquitous. Would this be the best way to go?That or OpenMP, I guess. But as Ben said, goto comp.programming.threads.
One issue I''ve seen raised is about the "thread safety" of functions
in the Standard C library. Would it be fair to assume, on systems
where POSIX threads is implemented, that the Standard C library will
be thread-safe? Or is there a well-known way of asking the compiler to
ensure this, for example by defining the preprocessor directive
_REENTRANT?_REENTRANT is in the compiler''s namespace, so do not touch it unless
the compiler doc or some standard it follows says you should. There
will be some compiler option to make the compiler produce thread-safe
object code, link the right libraries, #define something like
_REENTRANT you can #ifdef on, etc. See the compiler''s documentation
for that switch, don''t try something just because it "seems to work".
--
Hallvard
这篇关于多线程C编程（适合那些喜欢移植的人）的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
