libtorque：可移植多线程延续，用于扩展的事件驱动程序
172 浏览量
更新于2024-08-25
收藏 273KB PDF 举报
"libtorque是便携式多线程延续库，用于构建可扩展的事件驱动程序，由Nick Black和Richard Vuduc在乔治亚理工学院开发。它旨在提高处理多路复用I/O的效率，是UNIX系统中事件和延续编程的最佳实践。"
libtorque是一个关键的库，它提供了在多种架构和操作系统上实现多线程延续的能力，以支持可扩展的事件驱动编程。这种编程模式自4.4BSD或POSIX.11之前就已经被证明是处理多路复用I/O的高效方法。随着时间的发展，libevent、libev、Java NIO等库变得非常流行，广泛应用于网络应用程序中。
传统的事件驱动模型通常使用单线程回调引擎，例如Firefox的多个功能分解事件循环、nginx的静态负载分布多进程以及Apache的mpm-worker模型（每个连接一个线程）。然而，随着多核处理器经济性的提升，开源领域对多线程I/O核心的需求增加。多线程回调引擎能够更好地利用并发工作负载，适应数据中心日益增长的多核硬件需求。
libtorque的出现，就是为了应对这一挑战，通过提供多线程延续机制，它使得动态并行成为规则而非例外。在UNIX网络编程中，它能够支持更高效的并发操作，以充分利用现代硬件的性能。libtorque的目的是解决单线程事件循环在处理大量并发连接时的性能瓶颈问题，使得应用程序能够更加灵活地扩展，以适应不断变化的工作负载和硬件环境。
此外，libtorque的设计考虑了移植性，使其能够在各种UNIX系统上运行，这使得开发者能够在不同的操作系统之间轻松迁移代码，保持软件的兼容性和一致性。对于需要构建高性能、可扩展网络服务的开发者来说，libtorque是一个强大的工具，它能帮助他们创建能够有效利用多核处理器并处理大规模并发连接的事件驱动应用程序。
libtorque是一个针对多线程和事件驱动编程的解决方案，它的设计和实现旨在提高可扩展性和性能，尤其适用于处理现代硬件中的并发工作负载。通过使用libtorque，开发者可以编写出更具弹性和效率的网络应用，适应快速发展的计算环境。
libtorque: Portable Multithreaded Continuations
for Scalable Event-Driven Programs
Nick Black and Richard Vuduc
Georgia Institute of Technology
nickblack@linux.com, richie@cc.gatech.edu
Abstract
Since before even 4.4BSD or POSIX.1
1
, programming via events and continuations has marked best
UNIX practice for handling multiplexed I/O
2
. The idiom’s programmability was proved sapient astride a
decade’s architectures and operating systems, as libevent [19], libev, Java NIO and others achieved ubiquity
among network applications. Academic [32] and proprietary systems have responded to multiproces-
sor economics with threaded callback engines, but such I/O cores remain rare in open source: Firefox uses
multiple functionally-decomposed event loops, nginx multiple processes with static load distribution, and
Apache’s mpm-worker variant a thread per connection. Economic employment of even COTS (Consumer
Off-The-Shelf) hardware already requires concurrent workloads, and manycore’s march into the data cen-
ter still more: dynamic parallelism as rule rather than exception. The community agrees that UNIX net-
work programming must change [6] [13], but consensus of direction remains elusive [14] [29]. We present
our open source, portable libtorque library, justify the principles from which it was derived, extend previous
threaded cores through aggressively exploiting details of memories, processors, and their interconnections
(as detected at runtime), and imply a new state-of-the-art in architecturally-adaptive, high-performance
systems programming. Built with scalability (in both the large and small), low latency, and faithfulness to
UNIX idiom as guiding lights, libtorque subsumes the functionality of existing I/O frameworks (for which
we provide compatibility wrappers) despite superior performance across most loads and apparatus.
1 Intro
It’s a rare and rather lucky program which spends
most of its wall time calculating. Whether an inter-
active application, a desktop widget, or a network
server, relative eternities are made up of waiting for,
shuffling, and signaling the presence of data. Spin-
ning on event readiness implies ineffective use of
processor and power, motivating event registration
and data readiness notification schemes (of which
blocking I/O—with or without a timeout—can be
thought the uniplex special case. Each thread has
a single channel, bound to a single source). This
concept forms the essential omphalos of POSIX’s sys-
tem interfaces: Pthread condition variables, asyn-
chronous I/O, and humble read(2) can all be inter-
preted as some mapping between threads and event
sources, with the goal always of sleeping as much as
local service requirements allow. Every non-trivial
program will use them at least once.
Given our definition of blocking I/O, spinless
employ of multiple event sources requires either
multiple threads or multiplexed, non-blocking (pos-
sibly asynchronous, i.e. kernel-demultiplexed) I/O.
The former solution, at the cost of O(n) threads and
O(n) context switches for n event sources, retains
the simplicity and streamline (thanks to the absence
of any multiplexing interfaces) of blocking. With
the advent of Linux’s NPTL and FreeBSD’s libthr,
this method has seen a resurgence, and even argu-
ment a posteriori that its performance might exceed
that of multiplexed I/O [31]. That this is possible—
that O(n) time and space costs are negated by multi-
plexing overhead, as evidenced in [28]—shows how
much room for improving non-blocking I/O solu-
tions exists on modern machines. We enumerate
and address five possible overheads: memory ef-
fects, multiplex setup (“enplexing”?), synchroniza-
tion within the system call, walking of the event ta-
ble, and copying the results to userspace. We il-
lustrate several ways I/O-intensive applications can
(and libtorque does) make effective use of system ar-
chitecture properties. We show that a tradeoff ex-
ists between dynamic balance under arbitrary load
1
select(2) first showed up in 4.2BSD, poll(2) in SVR4.
2
As canonicalized within the books of W. Richard Stevens [24].
1
下载后可阅读完整内容，剩余5页未读，立即下载
2018-04-04 上传
2021-04-22 上传
2021-04-22 上传
2021-07-03 上传
2022-09-19 上传
2021-06-29 上传
2015-08-01 上传
2021-05-12 上传
2021-02-09 上传
weixin_38624975
- 粉丝: 5
- 资源: 907
我的内容管理
展开
