C 线程,跨平台

发布于 2024-10-31 14:05:49 字数 171 浏览 2 评论 0原文

我正在处理一个当前在单线程上运行的现有项目(C 语言),我们希望在多个平台上运行并拥有多个线程。希望有一个库可以实现这一点,因为,恕我直言,Win32 API 就像反复戳自己的眼睛。我知道 C++ 的 Boost.Thread,但是,这必须是 C(并且可以在 MinGW 和 gcc 上编译)。抱歉,Cygwin 不是一个选择。

I am dealing with an existing project (in C) that is currently running on a single thread, and we would like to run on multiple platforms AND have multiple threads. Hopefully, there is a library for this, because, IMHO, the Win32 API is like poking yourself in the eye repeatedly. I know about Boost.Thread for C++, but, this must be C (and compilable on MinGW and gcc). Cygwin is not an option, sorry.

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(8

这个俗人 2024-11-07 14:05:49

尝试 OpenMP API,它是多平台的,您可以使用 GCC 编译它。

wikipedia 的简要描述:

OpenMP(开放式多处理)是一个应用程序编程接口
支持多平台共享内存多处理的(API)
在大多数平台、处理器上使用 C、C++ 和 Fortran 进行编程[3]
体系结构和操作系统,包括 Solaris、AIX、HP-UX、
Linux、macOS 和 Windows。它由一组编译器组成
影响的指令、库例程和环境变量
运行时行为。

Try OpenMP API, it's multi-platform and you can compile it with GCC.

Brief description from the wikipedia:

OpenMP (Open Multi-Processing) is an application programming interface
(API) that supports multi-platform shared memory multiprocessing
programming in C, C++, and Fortran,[3] on most platforms, processor
architectures and operating systems, including Solaris, AIX, HP-UX,
Linux, macOS, and Windows. It consists of a set of compiler
directives, library routines, and environment variables that influence
run-time behavior.

忆梦 2024-11-07 14:05:49

我会使用 POSIX 线程 API - pthread。本文提供了在 Windows 上实现它的一些提示,以及仅头文件下载(BSD 许可证):

http://locklessinc.com /articles/pthreads_on_windows/

编辑:我过去使用 sourceforge pthreads-win32 项目进行多平台线程处理,它工作得非常好。从那时起事情就发生了变化,上面的链接似乎是最新的,尽管我还没有尝试过。当然,这个答案假设 pthreads 在您的非 Windows 目标上可用(对于 Mac / Linux,我应该认为它们是可用的,甚至可能是嵌入式的)

I would use the POSIX thread API - pthread. This article has some hints for implementing it on Windows, and a header-file-only download (BSD license):

http://locklessinc.com/articles/pthreads_on_windows/

Edit: I used the sourceforge pthreads-win32 project in the past for multi-platform threading and it worked really nicely. Things have moved on since then and the above link seems more up-to-date, though I haven't tried it. This answer assumes of course that pthreads are available on your non-Windows targets (for Mac / Linux I should think they are, probably even embedded)

音盲 2024-11-07 14:05:49

与 Linux 相比,Windows 线程具有截然不同的功能,因此也许您应该考虑两种不同的实现,至少在应用程序性能可能成为问题的情况下如此。另一方面,简单地实现多线程很可能会使您的应用程序比以前慢。让我们假设性能是一个问题,并且多线程是最佳选择。

对于 Windows 线程,我特别考虑 I/O 完成端口 (IOCP),它允许实现 I/O 事件驱动的线程,从而最有效地利用硬件。

许多“经典”应用程序都是按照一个线程/一个套接字(/一个用户或类似)概念构建的,其中同时会话的数量将受到调度程序处理大量线程(>1000)的能力的限制。 IOCP 概念允许将线程数量限制为系统中的核心数量,这意味着调度程序几乎不需要做任何事情。仅当 I/O 事件发生后 IOCP 释放线程时,线程才会执行。该线程为 IOC 提供服务,(通常)启动一个新的 I/O 并返回以在 IOCP 处等待下一次完成。在释放线程之前,IOCP 还将提供完成的上下文,以便线程将“知道”IOC 属于哪个处理上下文。

IOCP 概念完全取消了轮询,尽管“等待多个对象”轮询在某种程度上是一种改进,但轮询是一种极大的资源浪费。我上次查看时,Linux 根本没有像 IOCP 那样的东西,因此与具有 IOCP 的 Windows 应用程序相比,Linux 多线程应用程序的构建方式将有很大不同。

在真正高效的 IOCP 应用程序中,存在这样的风险:大量 IO(或更确切地说输出)排队到所涉及的 IO 资源,导致系统耗尽非分页内存来存储它们。相反,在效率非常低的 IOCP 应用程序中,存在这样的风险:大量输入排队(等待服务),导致在尝试临时缓冲它们时非分页内存耗尽。

Windows threading has sufficiently different functionality when compared to that of Linux such that perhaps you should consider two different implementations, at least if application performance could be an issue. On the other hand, simply implementing multi-threading may well make your app slower than it was before. Lets assume that performance is an issue and that multi-threading is the best option.

With Windows threads I'm specifically thinking of I/O Completion Ports (IOCPs) which allow implementing I/O-event driven threads that make the most efficient use of the hardware.

Many "classic" applications are constructed along one thread/one socket (/one user or similar) concept where the number of simultaneous sessions will be limited by the scheduler's ability to handle large numbers of threads (>1000). The IOCP concept allows limiting the number of threads to the number of cores in your system which means that the scheduler will have very little to do. The threads will only execute when the IOCP releases them after an I/O event has occurred. The thread services the IOC, (typically) initiates a new I/O and returns to wait at the IOCP for the next completion. Before releasing a thread the IOCP will also provide the context of the completion such that the thread will "know" what processing context the IOC belongs to.

The IOCP concept completely does away with polling which is a great resource waster although "wait on multiple object" polling is somewhat of an improvement. The last time I looked Linux had nothing remotely like IOCPs so a Linux multi-threaded application would be constructed quite differently compared to a Windows app with IOCPs.

In really efficient IOCP apps there is a risk that so many IOs (or rather Outputs) are queued to the IO resource involved that the system runs out of non-paged memory to store them. Conversely, in really inefficient IOCP apps there is a risk that so many Inputs are queued (waiting to be serviced) that the non-paged memory is exhausted when trying to temporarily buffer them.

东走西顾 2024-11-07 14:05:49

这里的“最好”/“最简单”/...答案肯定是 pthreads。它是 Unix/POSIX 系统上的本机线程架构,并且在 Windows 上几乎同样有效。无需再进一步寻找。

The "best"/"simplest"/... answer here is definitely pthreads. It's the native threading architecture on Unix/POSIX systems and works almost as good on Windows. No need to look any further.

迷路的信 2024-11-07 14:05:49

如果有人需要一个可移植且轻量级的 C 线程解决方案,请查看 plibsys 库。它为您提供线程管理和同步,以及其他有用的功能,例如便携式套接字实现。支持所有主要操作系统(Windows、Linux、OS X),还支持各种其他不太流行的操作系统(即 AIX、HP-UX、Solaris、QNX、IRIX 等)。在每个平台上,仅使用本机调用来最小化开销。该库完全覆盖了定期运行的单元测试。

If someone needs a portable and lightweight solution for threading in C, take a look at the plibsys library. It provides you thread management and synchronization, as well as other useful features like portable socket implementation. All major operating systems (Windows, Linux, OS X) are supported, various other less popular operating systems are also supported (i.e. AIX, HP-UX, Solaris, QNX, IRIX, etc). On every platform only the native calls are used to minimize the overheads. The library is fully covered with Unit tests which are run on a regular basis.

伊面 2024-11-07 14:05:49

glib 线程 可以跨平台编译。

glib threads can be compiled cross-platforms.

£冰雨忧蓝° 2024-11-07 14:05:49

鉴于您受限于 C。我有两个建议:

1)我见过一个项目(与您的类似)必须在 Windows 和 Linux 上使用线程运行。它的编写方式是(相同的代码库)在 Linux 上使用 pthreads,在 Windows 上使用 win32 线程。这是通过在需要创建线程的地方使用条件 #ifdef 语句来实现的,例如

#ifdef WIN32

//use win32 threads

#else

//use pthreads

#endif

2) 第二个建议可能是使用 OpenMP。您考虑过 OpenMP 吗?

如果我错过了什么或者您想了解更多详细信息,请告诉我。我很乐意提供帮助。

最好的,
克里希纳

Given that you are constrained with C. I have two suggestions:

1) I have a seen a project (similar to yours) that had to run on Windows and Linux with threads. The way it was written was that it (the same codebase) used pthreads on Linux and win32 threads on Windows. This was achieved by a conditional #ifdef statement wherever threads needed to be created such as

#ifdef WIN32

//use win32 threads

#else

//use pthreads

#endif

2) The second suggestion might be to use OpenMP. Have you considered OpenMP at all?

Please let me know if I missed something or if you want more details. I am happy to help.

Best,
Krishna

橪书 2024-11-07 14:05:49

根据我的经验,C for Windows 中的多线程与 Win32 API 密切相关。框架支持的其他语言(例如 C# 和 JAVA)在提供线程类的同时也与这些核心库相关联。

不过,我确实在 sourceforge 上找到了一个 openthreads API 平台,它可能会对您有所帮助:

http://openthreads.sourceforge.net/

API 是根据 Java 和 POSIX 线程标准建模的,

我自己还没有尝试过,因为我目前不需要在我的 C/C++ 项目上支持多个平台。

From my experience, multi threading in C for windows is heavily tied to Win32 APIs. Other languages like C# and JAVA supported by a framework also tie into these core libraries while offering their thread classes.

However, I did find an openthreads API platform on sourceforge which might help you:

http://openthreads.sourceforge.net/

The API is modeled with respect to the Java and POSIX thread standard,

I have not tried this myself as I currently do not have a need to support multiple platforms on my C/C++ projects.

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文