软件目录(www.cnosoft.com)5月13号讯:
模块分离:许多开发者所维护的多执行绪模式的工程,或多或少都会遇到以下问题:在不同的模块之间进行直接呼叫,不信任的话,那么,您的专案肯定是一个模组的。我想大多数时候,都会有一些函数被调用,或者是没有全局变量的时候,这些都是很好的例子。
因为多线程天生的优点,可以看到彼此的地址,这就使得直接的呼叫变得非常简单,许多新手都是如此。可以轻松地编写出一个简单而又粗糙的界面,如果有 static的功能,为了省事,可以省略 static,直接使用。这样一来,随着项目的增加,各个模块之间的交叉越来越多,耦合也越来越强。
我支持多进程,是因为多个过程可以屏蔽掉这些“方便”的交流,让我们在做一个模块的时候,会不会考虑到有没有必要。然后再考虑界面的定义(由于处理之间的通信比较复杂,所以开发者会更多地考虑界面和协议的概念,以尽可能地降低界面的影响。这就像是生活一样,一帆风顺,谁也不会去多想。想的东西多了,路也多了,也就不一样了。
因此,我的观点是,多处理模式迫使你更多地考虑如何设计,并在实际中降低了模块间的耦合。
将多个多线程模式转换成多处理模式时,往往会在多个处理模式中出现一些重复的界面,这是由于界面函数是在一个进程中,所有人都可以调用的。例如, A通过 A、 B被呼叫, A和 B被分成两个不同的过程。界面 A要在 A和 B中单独地完成,不做任何说明,因为在软件工程学中,重复的代码是最忌讳的。一定要清除掉。方法也非常的容易,就是将多个不同的模块所呼叫的界面分开,形成一个 lib,让其它的程序可以进行呼叫。您找到了哪些,是否可以将其分离出来,成为一个整体的公共部件,非常好。在 lib下面,是一个公共的基本部件,在每个部件中都有一个单独的商业流程。
容易找到:在多执行绪模式下,如果另一个执行绪出现了故障,则会造成一个完整的处理结束,当然,根据 crash的讯息,可以判断该线程已经死亡。但是,如果这个线程的组件是多个团队和人来维持的,那么在这个过程发生故障之后,团队会做出怎样的决定。这个问题很大,有时候也会发生在一个线程上,但实际上是其他的线程的问题(连接的麻烦),这样的话,团队之间不可避免的会发生争执和互相推卸责任。(那些信心满满的程序员,都觉得我的程式没有任何问题)
而如果使用多个过程模式,那么,您的服务流程就会中断,您可以自行寻找其中的理由。无话可说。
简单的性能检测:在多行程中,单一的线程并不容易被发现(或者说,在某些嵌入式系统中,并没有一个完整的指令),在处理过程中,在处理过程中,需要大量的资源来进行处理。但如果是一个多进程的模式,那么就可以查看哪个线程占用了多少的资源,这是一个很小的问题。相同的体系,被分割为多个过程,单一的过程要比单一的过程要简单的多,从而减少了复杂程度。这样的话,想要找到自己想要的东西,就更简单了。
分布:网络产业一向注重分布,云计算,嵌入式产业,都是一件很麻烦的事情,似乎并不是必须要有分布的。这倒也是,大多数时候,都是一个单独的芯片,可以单独工作。分散的情况很少见。但是,如果你把一块原本可以做的事情,分成两块,那么多个系统的扩展就会变得更加简单。
这只是一个很好的例子,嵌入式系统本身就是一个分散的产业,只不过它并没有从一个中心向一个分散的方向发展。
便利公司的密码授权分离:事实上,我非常讨厌这样的行为,公司应该信任自己的雇员,但是考虑到中国的诚实…所以,他必须要把自己的身体孤立起来。
在多执行绪模式下,之前说过,删除一个模组,您就不会 build了,这是要让所有的程式设计师都知道么。当然不行,每个模块都要提供一个类库,但我认为很常见,就是将一个公共的函数界面划分为一个公共的类库,而将一个与商业有关的组件也作为一个类库来使用。只是……
最后,我要说的是,这些都不是最重要的,没有一个可以让多个进程占据绝对的上风。就我的观点来看,多进程模式可以让工程师们去考虑如何去做。(任何一个有过这种问题的工程师都会考虑到任何一个模式)
既然已经说到这里,那就应该考虑一下,将以前的研究成果转化为多个过程,不然就是空中楼阁了。
首先要解决的问题,就是多个进程之间的交流,而多个线程之间的交流无法进行,所以,要怎么才能找到多个处理的通信模式?
linux下有许多 ipc方法,这里就不一一列出了,用于处理大量的数据,通信信息。最好的办法是套接,而在这个机器里,更多的是 unix socket,(这个方法有哪些优点?如果你想将一个单独的体系变成一个分散的体系,那么它的好处就会很大)
但如果只使用套接字来完成上述示例中的函数,就会出现以下问题:
同样的,第一个问题就是,我们之前的第二个解决办法,现在不能再在多个过程中使用了,这就很好理解了,不用再多说了。
最好的办法,就是在第一种情况下,将 Socket通讯改为 Socket通讯(通过 Socket通讯),不过,了解 Socket的工程师都知道,在进行 socket通讯之前,需要进行一系列的准备工作(主要是将两个组件联系在一起)。若加上 F组件,则 A也会与 F组件建立联系。在这种情形下,我们在脑海中绘制一幅联系图,就会发现我们编织了一幅由许多不同的网络组成的网络,这些网络中的每一个都有着复杂的联系。要对 A模块进行修改,这可比多线程模式要麻烦的多。这样的行为简直就是一场恶梦。
好了,怎么处理,我认为许多人都会考虑使用巴士分配。懂 android开发的人会想起 binder,懂 openwrt的人会想起 ubus,而懂电脑的人会想起 dbus,网络产业的开发者肯定也会知道 redis里面的 sub/pub模块。
以上的 binder, ubus之类的原则非常的简单,即创建一个信息中心,并构造一个转发路径。其它的模块没有进行直接的互动,取而代之的是信息中心的转送、路由,以及路由的确定。那么,使用预订/发行的观察模式来进行规则的界定。(C和嵌入式开发人员往往会认为,这种设计方式和 OOP相关,是唯一的,尽管现在已经有不少专家在这一领域推广了。但考虑到某些开发商的消息来源相对封闭,所以这个观点依然很流行)
根据此模式,我们可以很容易地满足上述示例的要求:增加一个信息核心,使所有的通讯组件都与此信息中心组件相关联。之后,您可以订购您所关心的活动,并且在事件出现时,您可以根据您的需求进行适当的操作。
因此,上述的模组 B、 C会在模组 a侦测到某个活动时,向外公布模组 a的活动。这个活动首先会被传送至信息中心,然后被信息中心传送至组件 b、 c,而新添加的组件 f。也仅需订购此模块,无需在更改至 A模块的程式码,即可扩充功能。