o**2
发帖数: 168 | 1 前言
===========================================================
FMP的核心理论一直没有变过， 之所以有1.0、2.0、3.0， 是因为分阶段推广的原因，
不同阶段对功能的要求有不同的取舍。 从目前的结果来看， 我的推广策划能力远远
不及我的编程能力， 所以干脆把FMP的全部功能一起推出来了， 也就是3.0。
3.0的东西我还没有在其他地方发过， 我觉得Mitbbs的小圈子挺不错的， 非常适合先
试试水， 希望能听听大家的意见， 高见和低见都欢迎， 只要不歪楼都行。 我在这里
邀请所有的人来参加讨论， 特别是zhaoce和goodbug， 我挺认同你们平时的一些看法
的， 希望你们能对3.0给出一些专业的意见。
FMP针对的是并发和分布编程， 并发主要是在单机内， 分布就是多机了。 FMP的独特
贡献是提供了一个统一的language independent的编程style和element， 轻松地把这
两个重大问题都解决了。 FMP提供的不是具体的系统或实现， FMP提供的是一个独创的
简洁的设计， 使得设计并发和分布系统... 阅读全帖 |
|
o**2
发帖数: 168 | 2 关于immutable objects
首先我要指出的是：immutable objects即不是FMP的goal，也不是FMP的feature，它们
和FMP没有关系。
多线程编程需要immutable objects，这样可以减轻出错的机会。因为你编这些object
的时候，不需要考虑thread safe了。
FMP中的每一个active object都是一个独立的处理中心，FMP保证每一个active object
的impl object及其用到的所有objects，都将运行在同一个单线程环境中。于是，
objects是不是immutable已经不是一个concern了。
FMP的message里的objects是要暴露在不同的线程里的，至少在一个caller object和一
个impl object里，这样就有两个thread了。
FMP的应对是允许用户选择他们觉得合适的messenger implementation。FMP是一个spec
，不同的software vendor可以提供不同的messenger impl。因为messenger impl的成
本很低，比如... 阅读全帖 |
|
o**2
发帖数: 168 | 3 费了老大的劲才把FMP的介绍塞进了2000个字符里。大家帮忙挑挑毛病。
Fast Messenger Programming (FMP) is a new object-based model for general
concurrent programming with NO threads.
FMP elements:
• Active objects – a type of virtual objects that represent business
functions
• Messenger objects – act as virtual machines to host and realize
active objects
• Text-based names – for FMP entities
An active object is defined as an object with:
• A name
• A list of services – each has a name and can be vie... 阅读全帖 |
|
o**2
发帖数: 168 | 4 JMS-like messaging middleware
FMP目前是作为一种通用的并发编程方法来推广的，是应用在object级别上，和中间件
的JMS实在扯不到一起去。不过FMP今后的确有进军企业级系统的潜力和计划，所以在这
里做一下比较。
FMP有两种寻址方法：一是message的发送方直接指定接受方；二是message的发送方和
接受方互不知道，也不需要一个中间方（比如一个topic），直接由第三方（比如admin
）给messenger提供routing rules来为message寻找接受方。
FMP的这两种寻址方法能覆盖publisher/subscriber寻址，但反过来却不能。比如，FMP
可以这样模拟pub/sub：指定一个active object act as a topic，subscribers把自己
的地址留给这个active object，而publishers则把message发给这个active object。
这样这个active object就可以把message转发给注册了的subscribers。
FMP的优势除了其本身的feature外，还... 阅读全帖 |
|
o**2
发帖数: 168 | 5 Spring @Async
这个可以从方便性，可靠性，和thread safe等角度来比较。（我没有实际用过Spring
Async，所依靠的都是临时search出来的reading。如有错误，欢迎指正。）
Async比Java标准的ExectorService强多了，这里就不再提ExectorService了，只比较
Async和FMP。事先说一下，FMP是完全没有静态type checking的，这样做的原因和好处
就不展开了，先认个输。
方便性
1，Async method只能返回void或Future，而FMP的impl object对return value没有任
何限制。这对caller来说，是一样的，但对那个method impl来说，是不同的。Spring
里同一个object的其它method如果要调用这个async method的话，就不能用sync的方式
了。而FMP的impl object完全是一个pure object，因为对外的是active object而不是
这个impl object，于是对外async，对内sync；当然对内也可以是async的，但要... 阅读全帖 |
|
o**2
发帖数: 168 | 6 上周 cplus2009 同学有个问题（http://www.mitbbs.com/article_t/Programming/31253813.html），涉及到GUI程序中线程之间转换的问题。就是controls都要在UIthread（Swing或SWT）里操作，而后台的logic要在非UIthread里操作。
我当时说了FMP可以轻易淘汰掉这种thread-base的编程技术，于是趁这个长周末，把对
UIthread的支持做进了FMP。想要试用的，可以在此download 2.0 jar：https://
github.com/fastmessenger/RI-in-Java/blob/master/fmp-2.0-bin.jar?raw=true
这里我借用 cplus2009 同学的问题作为范例：他的问题是有一个界面，上面有一个
BROWSE按钮，按了后弹出一个文件选择对话框。用户选好文件后，将文件名显示在
BROWSE按钮前面的text里。这里文件选择用来代表后台的耗时操作。
用FMP的，可以这样设计：一个Frontend class用来access UI controls... 阅读全帖 |
|
o**2
发帖数: 168 | 7 http://qt-project.org/doc/qt-4.8/signalsandslots.html
看了上面Qt Signals & Slots的文档，发现它和FMP不但本质不同，连表面都不同。我
这里就在Qt能做的事的范围内挑几条来简单比较一下，FMP能做而Qt不能做的就不提了。
1，被调用的class and methods
Qt：Slot functions除了和signals配合用之外，也可以当普通function来用。但是在
source里必须subclass QObject，并写上“public slots:”。
FMP：source里不需要任何特殊处理，只要注册的时候申明，如：guiMessenger.
registerJavaFxReceiver (this, "file.frame", "setStatus")。
FMP也可以使用marker interface IReceiver来写class and methods：
public class Calculator implements IReceiver {
public Object onPor... 阅读全帖 |
|
o**2
发帖数: 168 | 8 有本质的不同，体现在FMP比task更进了一步。首先，FMP把这些task集中起来放在一个
active object里了；然后再对这个active object抽象了一次，把它完全变成了一个
object的spec；最后，由其它一个（甚至多个）solid的impl object来实现这个spec。
(see figure below)
FMP里的messenger object是整个体系的关键，不同的messenger implementations只要
能维持active object的spec和语义一致不变，那user programs就完全不受影响了。于
是messenger object在内部怎么搞都可以了，比如：可以用一个impl object；可以用
多个impl objects来支持一个active object；甚至可以用非object，比如C，来实现这
个active object；再比如可以自由安排内部的thread等。
FMP对message的data type没有定义，完全留给实现者根据具体的语言决定其特定的风
格。这也导致了FMP不能实现在编译时做静态类型检... 阅读全帖 |
|
o**2
发帖数: 168 | 9 我在8楼列举了一些FMP的优点，不过一时半会儿是解释不清的。所以我说“进驻
Programming 版”就是长期从各个方面介绍FMP的特色。
FMP的核心是active object，并规定active object是virtual的，要一个virtual
machine来realize它们，Messenger就是这样一个virtual machine。
如果把active object看成是一个interface，就可以更好理解用户的责任：用户需要实
现这个interface声明的function。(上面的例子中有两个activeobject：“worker1”
和“worker2”，它们的function分别是do10seconds和do15seconds。)
用户怎么做呢？这由Messenger来定，比如我提供的reference implementation中的
Messenger支持三种方式：POJO (via reflection)，IReceiver，和ICallee。
FMP并不定义Messenger和用户之间的事，比如你完全可以开发一个你的Messenger，让
它支... 阅读全帖 |
|
o**2
发帖数: 168 | 10 Java最早的并发模型是直接使用thread；后来Java 5介绍了更高级一点的任务模型，也
就是ExectorService/Future，这个时候已经不是直接使用thread，而是把一些logic打
包成任务，然后扔给一个thread pool去执行。
我以前有一篇blog从比较文艺的角度比较thread，ExectorService，和FMP。结论是
FMP比ExectorService/Future还要高级，就象C比汇编高级的那种高级。
[obsolete] Fast Messenger: a high-level concurrent programming model
https://weblogs.java.net/blog/rexyoung/archive/2012/09/11/obsolete-fast-
messenger-high-level-concurrent-programming-model
这里我再从coding的角度比较一下FMP和ExectorService/Future，谈一下FMP的优点。
同时，我在这里发一个挑战，若有同学觉得某个程序用Exec... 阅读全帖 |
|
|
o**2
发帖数: 168 | 12 FMP特意和Actor Model拉开距离的，Carl Hewitt和Gul Agha的原始paper，以及Gul的
学生近年来做的东西，我都有看过。我深深体会到从73年就开始的actor model，从来
没有在mainstream deveoper里流行，真是有原因的。所以FMP全面采用OOP的用词，
active object在OOP里也是很早就提出了的。
至于和workflow engine相区别，我只能说FMP是用于通用编程的，并且目标就是no
thread，所以FMP不会变成thread library的。 |
|
|
o**2
发帖数: 168 | 14 这个比较不是为了定量地看谁快。首先，FMP号称no thread concurrency，所以使用
FMP的程序不需要直接使用thread，那我就要给个结果，证明FMP的程序的确并发了。
其次，就是我在上面回复中提到的参数 3 的作用。有结果显示的话，方便比较不同参
数的不同效果。
你说的“比如我的程序全面多线程 ，连打开文件那个OpenDialog都不直接打开文件而
是开始一个线程”涉及到了FMP的另一个优点，我在这里简单提一下，因为超出了本
post的scope。那就是messenger非常简单（我写的reference implementation只有900
行Java代码），用户可以自己定制的messenger。比如可以做一个给Swing程序用的
SwingMessenger（我以前提供过，以后也会再提供），然后在注册receiver的时候注明
这个receiver是用普通thread的，还是Swing thread的：
1) messenger.registerReceiver();
2) messenger.registerSwingReceiver(); |
|
o**2
发帖数: 168 | 15 这个参数 3 涉及了FMP的重要概念，就是active object。在FmpMain里面"calculator"
就是一个active object。FMP对调用和被调用的objects来说，都是no thread的，当然
messenger属于FMP系统object，最后还是要用thread来实现active object的。
FMP赋予了active object并发的语义：一个activeobject可以是一个single worker（
就是sequential programming）；也可以是一个team of workers（就是多个独立的
sequential programming）。所以这个 3 是head count的意思。
在computeDijkstraFormula（）里，每次调用"calculator:multiply" 3次，也就是说
这个算法的最大并发数是 3。于是参数 1 等于单个worker； 2 等于 a team of 2
workers； 速度也随之增快。但超过 3 之后，就不能在加快了。
对于调用和被调用的objects来说，这都是透明的... 阅读全帖 |
|
o**2
发帖数: 168 | 16 首要的好处是写并发程序更简单、更不容易出错了，因为FMP用active object取代了
thread。（当然不是一对一的简单替代。）
如果你对这个context有了解、并目前需要用多线程的话，我才好更有针对性的介绍FMP
的好处。（这个tutorial只是介绍FMP本身，供人查询和了解细节用的，并没有涉及到
对比和总结好处。）
这个前提是我经过无数挫折总结出来的，我的最终结论就是我只能面对面地对别人介绍
使用FMP的好处，因为要花很多时间把人带到特定的并发编程领域，然后才能涉及更细
节的东西。
你经常用多线程编程吗？ |
|
o**2
发帖数: 168 | 17 执行完了就可以比较返回值了。ExecutorService返回Future，FMP的callService()返
回IReturn，其实都是一回事，这点上来说，是平手。
但FMP的callServiceFor()支持event-driven programming style。主程序可以在
callServiceFor()指定另一个active object来接收返回值。
再次回顾FMP tutorial里的GUI example,可以看到即使在active object内，也可以轻
松调用其他任何的active object。这点是task做不到的。
当每个active object在一个method结束的时候都有能力发message给其他active
object，那你的程序可以轻易地判断谁结束了，完全不需要僵化的ExecutorService。
invokeAll()和invokeAny()。
在返回值和返回通知上，FMP胜。 |
|
o**2
发帖数: 168 | 18 首先，FMP和Java built-in的ExecutorService/Futre机制不是一个级别的东西。FMP在
这里只是展示它对imperative programming的支持。
其次，如果我们讨论的context仅仅限于这个例子的话，你的代码也缺了很多东西。要
写足了的话，会超过三行。
1）你要有一个ExecutorService，这相当与FMP的第50行；
2) worker1 & 2 必须是Callable或Runnable，改写的话，就超过了60/70这两行；
3) 你必须要有worker1和worker2的class源码，它们可能是同一个或两个不同classes；
4) 一个class里Callable或Runnable只能各implements一次；
5) messenger给它管理下的receivers（e.g. worker1&2）提供单线程环境。（这个有
点超出了刚才设定的context） |
|
o**2
发帖数: 168 | 19 这个范例展示的是FMP其中的一个feature: callFunction()。其实展示的内容和前两天
给出的代码片断是一样的，不过这里的是完整的、大家可以在自己的机器上运行的范例。
通过这个范例，大家可以观察：
1） 分别运行OopMain和FmpMain，visual地比较CPU的usages。
2） 比较OopMain和FmpMain源程序的异同。
3） FMP的灵活性，和其本身的大小（大约20K的jar，Java版的源码也就是900行）。
FMP把callFunction()设计成一个普通method call的replacement，当这个method本身
是相当独立的，就象这个范例展示的一样。 |
|
o**2
发帖数: 168 | 20 在这个特例上，FMP的使用方法的确和C#/Java的Task有类似之处。（顺便问一句，你是
做C#的吗？FMP也是有C#版的。）
所以我特意在FmpMain里面埋了个包袱，就是Object[] implObjs = new Object[3];
你有兴趣的话不妨试试把这个3改成其它的数字，比如1，2，4，5，6等，看看有什么区
别。应该会体会到FMP和Task有很大的不同。 |
|
c*****n
发帖数: 75 | 21 大概看了一下。 问几个问题。 （不是来挑刺的）。
1） FMP 和 Qt／Glib 的 Signal framework 有什么本质不同吗？ 好像都是 work
submission。 在submit work/task/ 的时候， caller 提供 target object, target
method, target arguments. 最后work给提供到一个eventloop里。 在 FMP里，
Messenger有eventloop 吧。
2） 对没有Runtime Type Information 的语言， 如C, C++， FMP 可用吗？Glib/C
implement了复杂的 Type System, Qt/C++ 提供了MOC compiler 来解决 C/C++ 的 RTI
问题。 |
|
o**2
发帖数: 168 | 22 最近正在写一个learn fast messenger programming by example的tutorial。计划有
以下这几篇，前三篇已经完成了，在http://fastmessenger.com/knowledgebase/。
已完成：
Example 1: Create a FMP program from refactoring
Example 2: Create a FMP program from scratch
Example 3: Implement active objects
快完成：
Example 4: An active object is a single headcount
Example 5: An active object could be a group headcount
Example 6: Active objects in GUI programs
（注1：single headcount概念用来说明一个active object在处理能力上相当于一个单
人。）
（注2：group headcount概念用来说明一个active ... 阅读全帖 |
|
o**2
发帖数: 168 | 23 你问的是：在这里推广FMP的好处？还是使用FMP的好处？ |
|
b***i
发帖数: 3043 | 24 比如，按下一个按钮要打开文件，能用你这个多线程读入文件吗？给个具体例子吧。
程序就叫FMPTest，extends JFrame,里面有一个JLabel,一个JButton, 要求点击
JButton打开FileDialog，选好文本文件后，用FMP线程读入，然后在JLabel里面显示
Good出现的次数。要求不能在UI线程里面读入文件。
FMP |
|
t****t
发帖数: 6806 | 25 我用多线程, 不过我觉得这不是很重要. 从前面的介绍来看, 很多人问, 但是你没有回
答的问题是: FMP和现有的future相比, 有什么好处? 从我自己的理解来看, 没有什么
明显的好处, 所以请你进一步介绍一下, 理论或者实例都可以.
FMP |
|
o**2
发帖数: 168 | 26
这里是完整的可运行的代码。需要的FMP库在： http://search.maven.org/#browse|1968728870
import com.fastmessenger.impl.GuiMessenger;
public class Main {
public static void main (String[] args) {
GuiMessenger messenger = new GuiMessenger ();
FMPTest win = new FMPTest (messenger);
FileAnalyzer analyzer = new FileAnalyzer (messenger);
messenger.registerSwingReceiver (win, "main.frame", "setStatus");
messenger.registerReceiver (analyzer, "file.analyzer", "countWord");
w... 阅读全帖 |
|
|
o**2
发帖数: 168 | 28
何做呢？
FMP本身不提供强制中断的机制，这和FMP的model有关，model里的每个active object
都是平等的，你只能发message发request给一个active object，但不能干涉它如何处
理它的message。
所以干涉或中断的责任就由用户承担了。比如之前的FileAnalyzer要实现“中断查找”
就要能接受两种message。一是开始，二是终止。然后在查找的过程中要时不时的暂停
，看看有没有终止message进来。这个暂停的效果，目前也是由用户用message来实现的。
下面是改写后的FileAnalyzer。
public class FileAnalyzer {
private GuiMessenger messenger;
private boolean working;
public FileAnalyzer (GuiMessenger messenger) {
this.messenger = messenger;
}
public void countWord (File file... 阅读全帖 |
|
o**2
发帖数: 168 | 29 首先，比较task的形式。ExecutorService只接受一个Runnable或Callable，而一个
Java class只能有一个Runnable或Callable，也就是说，一个class只能容纳一个task。
在FMP里，一个active object可以有任意多个methods（这里个一个method相当于一个
task），比如Example 3里的multiply()，divide()，和pow()。这要用
ExecutorService来写，就得用3个classes。
在组织结构上，FMP胜。 |
|
o**2
发帖数: 168 | 30 再来比较输入参数。Runnable的run()和Callable的call()，都不接受输入参数。如果
你的程序要给一个task设置参数，那你的主程序和这个task class都要有额外的处理。
Task class必须要加上必要的setters，主程序则要调用这些setter来设置输入参数，
然后才是submit给ExecutorService。
FMP tutorial里有一个完整可运行的GUI example，可以看到调用一个active object里
的method，只要一句就可以了：messenger.sendMessage ("file.analyzer:countWord"
, file, "Good");
http://www.mitbbs.com/article_t/Programming/31258831.html
更不用说不同的参数会带来task object的可重用性问题。
在输入参数上，FMP胜。 |
|
o**2
发帖数: 168 | 31 最后，FMP的messenger提供4种调用active object里method的方法（callService，
callServiceFor，sendMessage，publishMessage），ExecutorService根本都没有对应
的feature，FMP不战而胜。
先比较这些。 |
|
l*********s
发帖数: 5409 | 32 but thread in java is fairly trivial to write and it is the standard, there
is not much to gain by using fmp. |
|
o**2
发帖数: 168 | 33 贴程序是个好建议，多谢。
1) 有初始设置，但使用不会觉得verbose
2) 对，没有静态类型检查；和字符串无关
完整的比较现在还没有做，突出的有几点：
a) FMP是基于OOP的，同时支持imperative和event-driven programming
b) 除了直接指定receiving active object，还支持动态的routing addressing
c) 可以在其他OO甚至非OO语言上实现，用法一致 （现有Java，C#，和JavaScript版）
d) 支持两种thread models：Java和C#的shared-memory by threads；JavaScript的
dedicated-momery per thread
e) 支持progamming in the large：messenger除了是container外，还是building
block |
|
o**2
发帖数: 168 | 34 我不是很熟悉workflow engine，没有实战经验，不好比较。定性地说，FMP是用于通用
编程的，不仅仅限于workflow engine能做的事。
workflow |
|
o**2
发帖数: 168 | 35 这个在我的TODO list上都好几个月了，你不提，还真说不定要再过几个月才想得起来
。刚在 sonatype.org 上开了帐号和ticket，要等等。他们说：Normally it takes
less than 2 business days.
不过group id什么的现在可以定好了：
groupId: com.fastmessenger
artifactId: fmp-ref-impl
version: 2.0.0 |
|
|
t****t
发帖数: 6806 | 37 不知道netghost, 但是我是来问使用FMP的好处的, 前面你说了一堆, 我没看到什么好
处呀. |
|
|
o**2
发帖数: 168 | 39 把FMP收窄到和future相比，那就很好回答了。我准备一下，今晚或明天答复你。 |
|
o**2
发帖数: 168 | 40 作为一个open source project，FMP出来混总是要面对各种疑问的，我好好总结一下，
这个主题可以作为一个FAQ的条目。
欢迎多问问题 :) |
|
|
c*****n
发帖数: 75 | 42 还是看不出本质差别。你的tutorial你的例子用Qt的signal API可以轻易替换。在
performance上回有差别吗？ 就像我说问的， 你把每一个eventloop移到了对应
messenger里面。
比如，
在例５中，fileButton.setOnAction（）,
1) setOnAction() 在 SWING的eventloop 中执行， 并invoke 2)
2) file.analyzer:countWord 在 guiMessenger中执行， 并invoke ３)
3) file.frame:setStatus" 在 FileAnalyzer 的 Messenger中执行
可以看出active object 可自行定义messenger. 不如 ２）和３）的messenger 可以
是同一个thread eventloop 也可以是不同的。 这个自行定义messenger是否FMP的主
要优势？application在通常情况下要自行定义messenger吗？ |
|
|
o**2
发帖数: 168 | 44 所有的差异都源于两种思维模型的不同。FMP是以object为中心的，每个active object
就是一个自带能源的处理中心，并维持object级别上的encapsulation。就象example3
中的Calculator，它的multiply()，divide()，和pow()都是在一个object里。
example3: http://fastmessenger.com/kb-example-03/
而ExecutorService/Future却是建立在outsourcing的概念上的。它把一段代码打包成
task，然后提交给一个外部的ExecutorService/thread pool去执行。对简单的程序，
这也许不是问题，但逻辑复杂后，task多了后，这个程序变得越来越难控制，大量的精
力将被花在管理task，管理输入输出上。 |
|
o**2
发帖数: 168 | 45 在执行阶段，我们来比较task的重用性。一个task object（不是class）如果不需要输
入，还是有可能可以被重用的。但是重用同一个task object的话，那这个task object
的内部logic就被暴露在多线程的并发环境里了。
而active object有headcount的概念，一个headcount就是一个individual worker，于
是它的implementation object被保证了运行在单线程环境里。一个active object可以
是一个group of individual workers，每个worker有其自己的impl object，所以对
impl object来说，总是运行在单线程环境里。
Example 3 里的Calculator就是一个implementation object。
在执行阶段，FMP胜。 |
|
o**2
发帖数: 168 | 46 那我們回原先的 FMP Tutorial 裏談吧。
p.s. Sorry for the traditional Chinese as I am using pinyinput.com while
inputking.com is down the moment.
何做呢？ |
|
o**2
发帖数: 168 | 47 我不熟C++11的future，就不發表意見了。
你的建義，我能理解，我覺得適用於雙方計術水平和理念大致相當的前題下，只需要寥
寥數語就能捅破窗戶紙。我要推廣FMP，面對的人真的很多樣性，所以你的心意我領了。 |
|
o**2
发帖数: 168 | 48 受到找师傅的帖子的启发，发一个招生的：给愿意学习或使用FMP for concurrent
programming的同学（任选一个语言：Java, C#, or JavaScript - in either Browser
or Node.js），提供免费辅导。必要的时候，可以根据你的实际应用领域，提供定制
的messenger（就像上次zhaoce要求messenger支持JavaFX）。 |
|
|
o**2
发帖数: 168 | 50 可以说核心都是actor的思想，akka用户是使用裸体的actor，FMP的用户是通过
messenger使用active object。这个archtecture上的不同导致了vision的完全不同，
FMP完全是跨语言跨平台。不同语言不同平台上的不同active object可以用自始至终不
变的API互相调用/通讯，比如一个C#写的active object在messenger1里在Windows上可
以这样调用另外一个Java写的active object "calculator"which运行在messenger2在
Linux上：
messenger1.callService("messenger2::calculator:multiply", n1, n2);
（当然前提是messenger1和messenger2已经直接或间接地connected，FMP叫它们
networked messengers。模型和设计都完成了，就等有空的时候，我写一个reference
implementation。）
（n1和n2要是合适的数据，比如可以写成JSON的。FMP不管数据转换的... 阅读全帖 |
|
