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)。
- 游戏开发中的多风格系列场景,比如道路,房屋,管道等。