o**2
发帖数: 168 | 1 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的优点。
同时，我在这里发一个挑战，若有同学觉得某个程序用ExectorService/Future来写更
好的话，欢迎提出来，我用FMP来应战。
下面我分多楼来写这个比较，同学们可以插队，不用担心，不会影响我的。 |
o**2
发帖数: 168 | 2 所有的差异都源于两种思维模型的不同。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 | 3 首先，比较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 | 4 再来比较输入参数。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 | 5 在执行阶段，我们来比较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 | 6 执行完了就可以比较返回值了。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 | 7 最后，FMP的messenger提供4种调用active object里method的方法（callService，
callServiceFor，sendMessage，publishMessage），ExecutorService根本都没有对应
的feature，FMP不战而胜。
先比较这些。 |
b***i
发帖数: 3043 | 8 我比较关心如何中断一个线程的执行，比如昨天那个，加一个按钮，中断查找过程如何
做呢？
【在 o**2 的大作中提到】
: 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的优点。
: 同时，我在这里发一个挑战，若有同学觉得某个程序用ExectorService/Future来写更
|
t****t
发帖数: 6806 | 9 我是用C++的, 所以可能有点想当然了. C++11的future似乎没有这么多限制, 直接用
template调用就可以了, 也可以有参数, 当然template也自带type safety.
所以你这个还是有不少改进的.
但是我提个建议, 说长处就说长处, 本来几句话就可以说清楚的事情, 拉拉杂杂说了一
大堆, 让人很难抓住重点, 给人以吹法螺的感觉. 只是建议, 听不听在你. |
l*********s
发帖数: 5409 | 10 I had thought you are talking about future in java.
【在 t****t 的大作中提到】
: 我是用C++的, 所以可能有点想当然了. C++11的future似乎没有这么多限制, 直接用
: template调用就可以了, 也可以有参数, 当然template也自带type safety.
: 所以你这个还是有不少改进的.
: 但是我提个建议, 说长处就说长处, 本来几句话就可以说清楚的事情, 拉拉杂杂说了一
: 大堆, 让人很难抓住重点, 给人以吹法螺的感觉. 只是建议, 听不听在你.
|
|
|
o**2
发帖数: 168 | 11 那我們回原先的 FMP Tutorial 裏談吧。
p.s. Sorry for the traditional Chinese as I am using pinyinput.com while
inputking.com is down the moment.
何做呢？
【在 b***i 的大作中提到】
: 我比较关心如何中断一个线程的执行，比如昨天那个，加一个按钮，中断查找过程如何
: 做呢？
|
o**2
发帖数: 168 | 12 我不熟C++11的future，就不發表意見了。
你的建義，我能理解，我覺得適用於雙方計術水平和理念大致相當的前題下，只需要寥
寥數語就能捅破窗戶紙。我要推廣FMP，面對的人真的很多樣性，所以你的心意我領了。
【在 t****t 的大作中提到】
: 我是用C++的, 所以可能有点想当然了. C++11的future似乎没有这么多限制, 直接用
: template调用就可以了, 也可以有参数, 当然template也自带type safety.
: 所以你这个还是有不少改进的.
: 但是我提个建议, 说长处就说长处, 本来几句话就可以说清楚的事情, 拉拉杂杂说了一
: 大堆, 让人很难抓住重点, 给人以吹法螺的感觉. 只是建议, 听不听在你.
|
t****t
发帖数: 6806 | 13 I thought they are quite similar, but looks like the interface is quite
different.
【在 l*********s 的大作中提到】
: I had thought you are talking about future in java.
|
g*****g
发帖数: 34805 | 14 While Java Future does have a lot of boiler plate codes, other frameworks
have simplified it quite a bit. Spring, for example, can use AOP to declare
a method asynchronous, all it takes is one annotation.
@Async
void myMethod()
Obviously you can have multiple Async tasks in one class. You can call other
Async tasks. You can pass parameters you want without constructing a task,
and you can get a Future
back if you
want. And one important nice thing compared to your approach is that it's
strongly typed, unlike your string based reflection approach.
It's also fairly simple to pass around a Future and allow the receiver to
block on it. For the immutable part, in Java you can't prevent data sharing
without a deep clone. I am not convinced your framework is immunized of the
problem.
Now for more complicated messaging model, like publisher/subscriber, it's
been taken care of in other frameworks such as JMS, with sophisticated
support like transaction and security built in.
countWord"
【在 o**2 的大作中提到】
: 再来比较输入参数。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 | 15 非常感谢你的反馈，我会逐一答复反馈中的三个方面：Spring @Async；Immutable
objects；和JMS等。
declare
other
task,
【在 g*****g 的大作中提到】
: While Java Future does have a lot of boiler plate codes, other frameworks
: have simplified it quite a bit. Spring, for example, can use AOP to declare
: a method asynchronous, all it takes is one annotation.
: @Async
: void myMethod()
: Obviously you can have multiple Async tasks in one class. You can call other
: Async tasks. You can pass parameters you want without constructing a task,
: and you can get a Future
: back if you
: want. And one important nice thing compared to your approach is that it's
|
o**2
发帖数: 168 | 16 关于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的成
本很低，比如FMP提供的reference impl只有900多行Java代码，其中还有大量的空行。
这个messenger impl的选择自由不是针对immutable objects问题的，比如
GuiMessenger就能用GUI thread来执行用户指定的active object。（参见FMP
Tutorial：http://www.mitbbs.com/article_t/Programming/31258831.html）
当一个用户需要immutable objects作为message发出去的话，可以选用一个特定的
messenger impl，这个impl自动deep clone所有的message objects。 |
o**2
发帖数: 168 | 17 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外，还有很重要的一点是它的统一性。用FMP在微观的
object上编程，和用FMP在enterprise的object/component上编程，是一样的。
这样不但做core Java的能在enterprise Java上继续贡献，enterprise上的很多好东西
也能向下在微观object的级别上使用，比如：SOA，client/server，web service，etc. |
o**2
发帖数: 168 | 18 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的，但要经过
messenger来调用。
2，Async是mark在method source code上的，光读调用部分的话，读的developer不知
道这个invocation是async的，还是sync的。FMP没有这个问题，通过messenger invoke
的，都是async的。
可靠性
据说Spring是通过AOP来做Async的，所以async调用有不work的时候。Spring doc自己
说不能用在@PostConstruct中。我在stackoverflow.com也看到async在其它有些情况下
也不work。http://stackoverflow.com/questions/6610563/spring-async-not-working
FMP的messenger是pure object，always works any where any time。
Thread safe
Async能方便地mark一个method，caller也能非常方便地调用这个method，但这些都只
限在method的级别上。让一堆method async运行，并没有增进thread safe；相反，
async的method增加后，整个object或program更不thread safe了。
FMP关注的并不是method这个级别，而是整个object。简单地说，FMP让整个active
object async了，因为整个active object在一个时刻只能有一个method在运行，而不
同的active object之间是并发的。 |
o**2
发帖数: 168 | |
