软件架构、并行处理和异步模式
可能的重复：
有关于并行架构设计模式的好资源吗？
我发现我的代码越来越多地朝着异步和并行的方向发展。我从事 Web 应用程序工作，并且必须处理 Web 服务（客户端 > 服务器和服务器 > 服务器）。我正在寻找有关异步和并行编程的软件架构和设计模式的优质资源。
为了稍微控制一下事情，让我们重点关注使用异步技术实现的并行编程的模式和架构。重点关注内置回调支持的语言。
Possible Duplicate:
Any good resources on design patterns for parallel architectures?
I'm finding more and more of my code going in the direction of asynchronous and parallel. I work on web applications, and have to deal with web services (both client > server, and server > server). I'm looking for good resources on software architecture and design patterns for asynchronous and parallel programming.
To reign things in a little, lets focus on patterns and architectures for parallel programming achieved using asynchronous techniques. Focusing on languages which have built in support for callbacks.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
恕我直言，关于这个主题（软件架构、并行处理和异步模式）的唯一/最好的书是 “Windows 上的并发编程”，作者：Joe Duffy。
是的，它的标题中有“Windows”，但不要被它欺骗了。这是 958 页的认真思考，作者在现实世界中积累了几十年的“便笺”，涉及并发编程的重要概念，这些概念在其他地方找不到（系统、硬件、虚拟机、语言等） .）（恕我直言，“为什么我写这本书”非常有趣。）
无论您使用哪种语言和平台，其中都包含大量信息。本书的前半部分只是让你思考这个问题。当 Windoze 的东西出现时，了解“可重用”架构示例可能是什么样子、好与坏以及做出的牺牲仍然很有帮助。有一些 Windoze 特定的东西（例如，线程“纤维”），但即使这样也可以显示（1）问题是什么（例如，昂贵的线程上下文切换），以及（2）可能的解决方案（例如，单独的来自线程的数据堆栈，因此数据堆栈切换很快）。我不使用光纤，也不使用太多/任何特定于 Windoze 的“可重用库”，但这些权衡对于您理解非常重要（例如何时在任何给定平台上使用“通用”线程池，以及何时编写自己的）。
它讨论了很多常见的设计选项，例如（典型的）“线程窃取工作队列”，其中“任务”被创建并添加到队列中，并且每个线程“窃取/吃掉”当线程可用时，这些项目来自 FIFO 队列。简而言之，本书讨论了如何以不同的方式思考问题，而不是历史上的面向对象或命令式方法。
例如，在读了几次这本书（以及从其他地方收集到的一些其他信息）后，我们重写了所有内容：我们永远
sleep()我们的线程了。它们始终以 100% 的速度工作，或者被交换（就像在“线程池”中，当有新工作要做时就会被唤醒）。即使对于并发性，也有一些新颖的方法来“思考问题”，使您重新编写（写得非常好的）英语学期论文，使其写得更加好。正如您提到的，回调是一种方法。我通常使用“类似函子”的东西来实现那些处理跨线程信号或数据的跨线程封送等问题的东西。
signal/slot范式也能很好地解决这个问题，并且像 Qt 这样的一些实现可以很好地处理跨线程信号。然而，这个主题如此庞大，以至于我犹豫是否要深入挖掘任何给定的设计方法或语言来进行此类讨论......但是，像您一样，我必须从某个地方开始< /em>.这本书（我今年春天读的）帮助我真正“形式化”了我对并发的理解，尽管我已经在许多系统/平台上使用许多不同的设计方法接触了硬件/软件并发多年。 。
如果您找到另一本这样的书，请告诉我……我也想读那本书（确实需要“反转”大脑，以便在异步/并发/并行的背景下自然地适应设计选项），我发现的关于这个主题的大多数内容都非常狭窄于特定的语言或技术。
IMHO the only/best book on this topic (software architecture, parallel processing, and asynchronous patterns) is "Concurrent Programming on Windows" by Joe Duffy.
Yes, it has "Windows" in the title, but don't let that fool you. It's 958 pages of serious consideration for the couple-of-decades of "sticky notes" the author accumulated in real-world settings on important concepts with concurrent programming that you won't find elsewhere (systems, hardware, virtual machines, languages, etc.) (The, "Why I wrote this book" is quite interesting, IMHO.)
There's a tremendous amount of information there, no matter your language and platform. The first half of the book is to simply get you to think about the problem. When the Windoze stuff shows up, it's still helpful to understand what "reusable" architecture example(s) might look like, with good-and-bad, and the kinds of sacrifices made. There are a few things Windoze-specific (e.g., thread "fibers"), but even that serves to show (1) What was the problem (e.g., expensive thread context switch), and (2) A possible solution (e.g., separate the data stack from the thread so the data stack switch is fast). I don't use fibers, nor much/any of the Windoze-specific "reusable libraries", but those trade-offs are really important for you to understand (such as when to use the "generic" thread pool on any given platform, and when to write your own).
It talks a lot about common design options, like the (typical) "Thread-Stealing-Work-Queue" where "tasks" are created-and-added-to-a-queue, and each of the threads "steal/eat" those items from the FIFO queue when the threads are available. In short, the book talks about how to think about the problem differently, as opposed to historical OO or imperative approaches.
For example, after reading the book a couple times (and some other information gleaned elsewhere), we rewrote all our stuff: We NEVER
sleep()our threads anymore. They are always working at 100%, or swapped out (like in a "thread pool" that wakes up when there is new work to be done). Even for concurrency, there are novel ways to "think about the problem" that make you re-write your (very well-written) English Term Paper so that it is even more well-written.As you mention, callbacks are one approach. I typically implement those with "Functor-like" things that handle issues like cross-thread signaling or cross-thread marshaling of data. The
signal/slotparadigm works well for that too, and some implementations like Qt's handle cross-thread signalling very nicely. However, this topic is so huge that I hesitate to dig too closely to any given design approach or language for this type of discussion...But, like you, I had to start somewhere. This book (which I read this Spring) helped me really "formalize" my concurrency understanding, even though I've got a number of years of exposure to hardware/software concurrency on a number of systems/platforms with a bunch of different design approaches.
Let me know if you find another book like this one ... I'd like to read that one too (one really needs to "invert" one's brain to naturally flow with design options within the context of asynchronous/concurrent/parallel), and most stuff I've found on this topic is pretty narrow to a given language or technology.