电信软件硬多线程问题的设计模式

Question

在企业应用程序架构的Martin Fowler's book 模式中，他在第2页写道：“在某些方面，企业应用程序比电信软件容易得多 - 我们没有非常难的多线程问题...“。

是否有人知道这些“非常难以解决的多线程问题”和解决方案的摘要，以设计模式的形式，如着名的GoF 设计模式书？

有POSA book。但这些书可能过于笼统和根本。更多以域名为中心的例子就是这个问题。

Answer 1

查看Joe Armstrong 2003年的论文：

<强> Making reliable distributed systems in the presence of software errors

阿姆斯特朗在爱立信任职期间为高速网络交换设备设计了该软件。它是在Erlang中实现的，它专门用于提供高度可靠和高度并发的应用程序。

在他的论文中，他介绍了Erlang语言本身和OTP（开放电信平台）库的基础设计决策。他还就如何为这些应用程序设计应用程序模块提出了一些建议 - 这部分最接近你的“设计模式”，尽管在阅读GoF的设计模式后你已经习惯了这个细节。

这不是一本食谱书，但他仍然就如何设计应用程序得出了一些有趣的结论。

Answer 2

演员

actor model一种架构模式，其中系统由一组松散耦合的演员组成，这些演员通过消息传递进行交互。

  

演员是一个计算实体，为了响应它收到的消息，可以同时执行：

     

  
• 向其他演员发送有限数量的消息;
  
• 创建有限数量的新演员;
  
• 指定用于收到的下一条消息的行为。
  

这种系统的一个特性是减少了故障传播，因此个体参与者变得更加健壮。

编程语言Erlang专为电话交换机设计，支持演员模型。

国家机器

实时和常见的模式嵌入式软件工程是状态机。状态机可以在actor之上实现，但也提供表示复杂状态和相关行为的机制。

有限状态机（FSM）是一种可能性，但由于State Explosion，它们很快就会变得庞大且难以维护。解决这个问题的更具表现力的形式主义是Hierarchical State Machines (HSM) as originally developed by David Harel。

适用于面向对象设计的相同语义的最新实现是UML状态机，请参阅Section 15 of the UML specification。这为状态机定义了一个完整的执行语义模型。