1.actor-based programming
actor based 类似于object based ,但是它比object 多了自己的message queue 和message processor、message handler
也就是说一个actor是一个独立的处理单元,但是他不是真正的物理上的thread
可以看成是轻量级的thread。
一个actor可以给另一个actor push msg
这样系统中就可以存在大量的独立活动单元,是并行系统的基本组件。
2.Intel TBB(Threading Build Block)
这是intel的一个开源的高性能线程库,它可以很大效率的支持多个任务的并行(这是隐藏实际的物理的thread的),我们可以把上面的actor分配给TBB去调度管理,来实现高性能的并行系统。
这个库还提供了各种thread-safe的container,而我们知道标准c++的stl的container都是线程不安全的。
感想
这种actor-based方法让我想到了QT中的Qwidget,他们可以互相通信,有各自的message queue,但是不同的是Qwidget是单线程的,没有一个多线程库去对他们之间做并发。
使用actor-based方法构建并行系统,比我们单纯使用多线程来实现的好处是:
1.纯多线程的系统受线程数量的影响,当系统复杂度提高时,线程数目要升高,会降低性能甚至不能扩展系统。
2.纯多线程的系统一般要使用lock critical area等来对线程进行互斥,当系统复杂度提升时,各种dead lock等问题也会出来,降低性能。而actor-based是share nothing的,一个actor里面的数据是相互独立的,不必使用线程间的互斥和等待。
但是个人认为这种情况是理想的,有时还是要用锁的,关于这个,现在有一种transactional memory的东西来实现无锁的多线程并发,不过还处于实验阶段。
这里谈到的是系统间的调用关系与分析模型中边界类的区别,另外还提到了在分析模型和设计模型中的一点区别。
2013-03-26
福州-Thomas 男9:45:31
我想问问,在分析类中,如果某个控制类需要和第三方通信,那么第三方应该当作一个边界,那么在画图的时候是控制类发送消息到第三方的边界类去?
北京青润10:57:12
这应该是接口类,不是边界类。
北京青润 10:57:46
接口类属于非UI类型的类,有人把它划作边界类来定位。
北京青润 10:58:12
但是一般情况下,边界类指的就是UI相关的用户操作界面类。
福州-Thomas 男 15:18:56
分析类不是只有3种类型吗
福州-Thomas 男 15:19:08
边界控制 实体, 哪里的接口类?
福州-Thomas 男 15:25:49
分析类时序图,在搞支付平台,我们对接支付宝等,别的子系统再接我们平台
北京青润 15:25:54
这个要看你的整体架构设计是在哪一层进行数据通信的。
北京青润 15:26:08
一般来说这样的数据通信不可能在界面层。
福州-Thomas 男 15:26:14
嗯
福州-Thomas 男 15:26:22
在 service层
北京青润 15:27:29
这个接口的提供属于外部连接的实现,也就是系统内的逻辑关系体现,要看你的整体的架构实现思想。
一般来说都应该是在控制层进行的实现。
福州-Thomas 男 15:27:30
界面有可能在子系统,我们是做个支付的黑匣子系统,只对外暴露出 SOA 接口,子系统调用我们的接口与支付宝对接
北京青润 15:27:38
也就是mvc中的c中进行实现。
北京青润 15:27:57
到了设计模型阶段才会根据情况分离出来接口类和具体的实现关系。
福州-Thomas 男 15:28:28
哦,我们的 C 在实现时也会是个 serivce,没有 web mvc框架
北京青润 15:28:38
两个子系统或者子模块之间应该是c-c的调用关系。
北京青润 15:28:57
那就不要在分析模型阶段谈设计模型的事情
北京青润 15:29:24
不管它将来是什么形式,每一个阶段都要做自己的事情,跨阶段做开发的结果往往是得不偿失的。
福州-Thomas 男 15:29:44
那你在画支付用例的分析类时序图时候,和支付宝对接 不用表示吗
北京青润 15:30:19
分析模型要有分析模型的形态,只需要标记出来这里连接一个支付系统即可。
福州-Thomas 男 15:31:34
那这个支付系统 是 另外的一个 UML元素,还是 边界类来表示? 按道理说 第三方支付系统相对我们的支付平台也就是个边界,我们发请求给它
北京青润 15:32:16
自己的团队内部统一,可以通过一个message to self,上面加一个标签标识即可。
福州-Thomas 男 15:33:36
那为什么不能把它当作一个边界类呢
北京青润 15:33:56
它本来就不是一个边界类,你为什么非要当作边界类呢?
福州-Thomas 男 15:34:35
相对于我们自己的系统来说它就是个边界啊,我们在这个边界之外向它发送消息
北京青润 15:34:46
那是系统之外。
北京青润 15:34:57
这是系统间关系调用。
福州-Thomas 男 15:35:11
哦,
// CplusplusAbstractFactory.cpp : Defines the entry point for the console application. // #include "stdafx.h" #include<typeinfo> // "AbstractProductA" 草食动物 class Herbivore { }; // "AbstractProductB" 食肉动物 class Carnivore { public: // Methods virtual void Eat( Herbivore *h ) {}; }; // "ProductA1" class Wildebeest : public Herbivore { }; // "ProductA2" class Bison : public Herbivore { }; // "ProductB1" class Lion : public Carnivore { public: // Methods void Eat( Herbivore *h ) { // eat wildebeest printf("Lion eats %s\n",typeid(h).name()); } }; // "ProductB2" class Wolf : public Carnivore { public: // Methods void Eat( Herbivore *h ) { // Eat bison printf("Wolf eats %s\n",typeid(h).name()); } }; // "AbstractFactory" class ContinentFactory { public: // Methods virtual Herbivore* CreateHerbivore() { return new Herbivore(); } virtual Carnivore* CreateCarnivore() { return new Carnivore(); } }; // "ConcreteFactory1" class AfricaFactory : public ContinentFactory { public: // Methods Herbivore* CreateHerbivore() { return new Wildebeest(); } Carnivore* CreateCarnivore() { return new Lion(); } }; // "ConcreteFactory2" class AmericaFactory : public ContinentFactory { public: // Methods Herbivore* CreateHerbivore() { return new Bison(); } Carnivore* CreateCarnivore() { return new Wolf(); } }; // "Client" class AnimalWorld { private: // Fields Herbivore* herbivore; Carnivore* carnivore; public: // Constructors AnimalWorld( ContinentFactory *factory ) { carnivore = factory->CreateCarnivore(); herbivore = factory->CreateHerbivore(); } // Methods void RunFoodChain() { carnivore->Eat(herbivore); } }; int _tmain(int argc, _TCHAR* argv[]) { // Create and run the Africa animal world ContinentFactory *africa = new AfricaFactory(); AnimalWorld *world = new AnimalWorld( africa ); world->RunFoodChain(); // Create and run the America animal world ContinentFactory *america = new AmericaFactory(); world = new AnimalWorld( america ); world->RunFoodChain(); return 0; }
实现要点:
- 在抽象工厂模式中,选用哪种产品族的问题,需要采用工厂方法或简单工厂模式来配合解决。
- 抽象工厂模式和工厂方法模式一样,都把对象的创建延迟到了他的子类中。
- 具体的工厂类可以设计成单例类,他只向外界提供自己唯一的实例。
- 抽象工厂模式中的具体工厂负责生产一个产品族的产品。而产品族的增加只需要增加与其对应的具体工厂。
- 3种工厂模式都是创建型模式,都是创建对象的,但都把产品具体创建的过程给隐藏了。
- 工厂方法模式是针对一种产品结构,而抽象工厂模式是针对多种产品结构。
在以下情况下应当考虑使用抽象工厂模式:
- 一个系统不应当依赖于产品类实例如何被创建、组合和表达的细节,这对于所有形态的工厂模式都是重要的。
- 这个系统有多于一个的产品族,而系统只消费其中某一产品族。
- 同属于同一个产品族的产品是在一起使用的,这一约束必须在系统的设计中体现出来。
- 系统提供一个产品类的库,所有的产品以同样的接口出现,从而使客户端不依赖于实现。
- 支持多种观感标准的用户界面工具箱(Kit)。
- 游戏开发中的多风格系列场景,比如道路,房屋,管道等。