o**2
发帖数: 168 | 1 我这两年在搞一个工具，是open source的：http://java.net/projects/fastmessenger。使用者可以在不直接使用thread的情况下，用来写concurrent程序。看看这里有没有人感兴趣。 |
x*******6
发帖数: 262 | 2 请问和threadpool之类的工具有什么区别？总得给个Callable或者Runnable来提交任务
吧 |
o**2
发帖数: 168 | 3 在概念上和thread pool有很大的区别，thread pool是一个独立的execution power，
你把代码提交给它去运行，然后得到结果。Fast Messenger通过message driven把
execution power给内置到object里去了，变成了代码在object里面，它收到通知后就
自己找thread执行代码。
我刚好在最近的一篇blog里解释了这个区别：
英文：http://weblogs.java.net/blog/rexyoung/archive/2012/09/11/fast-messenger-high-level-concurrent-programming-model
中文：http://www.cnblogs.com/rexyoung/archive/2012/09/12/2681505.html |
N***m
发帖数: 4460 | 4 恕冒昧，我不懂，你这个和自己创建的thread有啥区别？
【在 o**2 的大作中提到】
: 我这两年在搞一个工具，是open source的：http://java.net/projects/fastmessenger。使用者可以在不直接使用thread的情况下，用来写concurrent程序。看看这里有没有人感兴趣。
|
o**2
发帖数: 168 | 5
这个区别有点象汽车的自动档和手动档的区别。你直接用thread，可以最贴心地控制硬
件的功能。但是对大多数的应用来说，更关心的是易用性和productivity。
我这样回答太虚了一点，要不你举个实际应用中的实例，我们用两种方法来讨论讨论？
【在 N***m 的大作中提到】
: 恕冒昧，我不懂，你这个和自己创建的thread有啥区别？
|
N***m
发帖数: 4460 | 6 你说的易用性是怎么回事？我觉得用thread已经很简单了
【在 o**2 的大作中提到】
:
: 这个区别有点象汽车的自动档和手动档的区别。你直接用thread，可以最贴心地控制硬
: 件的功能。但是对大多数的应用来说，更关心的是易用性和productivity。
: 我这样回答太虚了一点，要不你举个实际应用中的实例，我们用两种方法来讨论讨论？
|
s******e
发帖数: 493 | 7 read your blog. what is the difference between your stuff and java 1.5/1.6
executor framework? is it a wrapper on top of executor framework? |
o**2
发帖数: 168 | 8 的确，对有些问题来说，thread已经是很简单的了。
【在 N***m 的大作中提到】
: 你说的易用性是怎么回事？我觉得用thread已经很简单了
|
o**2
发帖数: 168 | 9 在blog post里，我把Java的executor framework归类成thread pool这一大类了。
Fast Messenger是用thread pool来实现的，因为最终来说硬件只有一种concurrency的
手段，就是threads。
FM有自己的一套programming model，所以不能算是thread pool的一层wrapper。但反
过来，FM可以模拟thread pool的功能。用thread pool的程序可以几乎结构不变地用FM
改写。
【在 s******e 的大作中提到】
: read your blog. what is the difference between your stuff and java 1.5/1.6
: executor framework? is it a wrapper on top of executor framework?
|
o**2
发帖数: 168 | 10 因为没有资源，FM这个project现在还没有什么文档，我计划在6个月到1年左右慢慢完
善。
各位提的问题都非常合理，只是在论坛的环境下，很多问题不能长篇大论地答复了，非
常抱歉。
我争取发一些具体的代码段啊什么的，这样可以讨论得起来。 |
|
|
e***l
发帖数: 710 | 11 感觉工作量并没有简化，只是换个形式，把逻辑放到那些objects里面去了。 |
o**2
发帖数: 168 | 12 你说得对，business logic放到那些object里去了。这是FM提供benefit给programmer
的开始：
1，这些object是active的，也就是你不需要安排thread什么的了。这很象browser和
website的关系，你发request，可以得到response。做dataflow也很方便。
2，这些object是有名字的，你用名字access它们，而不需要管它们的reference。
3，这些object的里面，你的business logic是在一个single threaded的环境里执行，
减少了race condition。
先想到这几点。
【在 e***l 的大作中提到】
: 感觉工作量并没有简化，只是换个形式，把逻辑放到那些objects里面去了。
|
g*****g
发帖数: 34805 | 13 估计就是Actor model吧。不知道跟Akka比起来有何优势？ |
o**2
发帖数: 168 | 14 从making object active这个角度来说，actor/agent/active object应该都算这一大
类的了。和普通的object比，这是决定性的一点。但在所有的actor-like的系统里，大
家都有这个基本点，所以反而是最不值一提的东西了。
我简单看过Akka的文档，觉得是一个很完善的系统，比如支持transactional
messaging。
FM和其他actor-like的系统比，优势在于：
1）紧抱着OO model的大腿，把自己看成OO的扩展，而不是actor model。作为结果，FM
目前提供在Java，C#和JavaScript上的implementation。
2）紧贴着developer for general programming，而不是research。完全没有陌生的
framework和syntax。
先写这两点，过几天我用FM写一个Akka tutorial里的PI示范程序，来比较比较。
【在 g*****g 的大作中提到】
: 估计就是Actor model吧。不知道跟Akka比起来有何优势？
|
o**2
发帖数: 168 | 15 By the way, how can I get email notifications for new replies as the
original poster? Thanks. |
s*******e
发帖数: 3042 | 16 仔细看了一下，感觉没有太多吸引力啊，现在的java thread model很成熟很好用，你
的tool的确是有新东西，但是看不出解决了什么问题，或者提供了什么更好的服务。 |
o**2
发帖数: 168 | 17 这个问题提得很好，只是不好回复，因为太open了，要等FM的文档齐了才能全面解释得
好。
这里我只是针对性地讨论一下。Thread相关的编程技术很成熟说明了对它的研究比较透
彻了。对它懂得更多并不等于它本身的性质和能力就更强更广了，同时，也并不等于大
多数人都掌握了。
其实对thread了解得更深，越发理解它只是bolts&nuts级别的coding工具，而在设计级
别上并不给力。比如，Brian Goetz 的书 Java concurrency in practice算不错了的
吧。全书通篇都是编码级别的东西，只有第6章从设计的角度谈了一下task，也就是众
所周知的thread pool的编程模式。
Thread没有提供有用的工具让程序员在设计软件结构等总体architecture的时候有所帮
助。Thread在设计的时候只是作为一个独立执行的概念出现的，比如这个模块要有自己
的thread独立执行，然后安排和其他模块如何交接task。在编码的时候thread相关的
API才会出来，这样在设计和编码阶段，thread在程序员脑子里的概念是不统一的。
即使对thread很了解了，可是不可能人人达到Doug Lea的级别，写多线程程序的门坎还
是挺高的。
Fast Messenger 除了能做到thread能做到的事外，还提供了一个统一的编程模型：不
但在设计阶段和编码阶段一致，还能跨语言（Fast Messenger在thread model不一样的
JavaScript上也能一样地实现了）。
【在 s*******e 的大作中提到】
: 仔细看了一下，感觉没有太多吸引力啊，现在的java thread model很成熟很好用，你
: 的tool的确是有新东西，但是看不出解决了什么问题，或者提供了什么更好的服务。
|
x*******6
发帖数: 262 | |
z*******3
发帖数: 13709 | 19 木有认真看你在做啥
不过从前面的人的说法看
貌似有两个东西你最好看看
一个是akka，akka有一个不好就是annotation支持比较差
如果你能做一个annotation支持的thread lib的话，还是有戏的
另外一个是work flow
work flow engine有一个标准叫做bpm
java的是jbpm，这个标准相对成熟
而且很多产品都已经可视化了，拖拖拽拽就搞定了
所以如果你想要继续
不妨认真思考一下这两个成型的产品系列会不会对你这个产品的生存造成冲击
programmer
【在 o**2 的大作中提到】
: 你说得对，business logic放到那些object里去了。这是FM提供benefit给programmer
: 的开始：
: 1，这些object是active的，也就是你不需要安排thread什么的了。这很象browser和
: website的关系，你发request，可以得到response。做dataflow也很方便。
: 2，这些object是有名字的，你用名字access它们，而不需要管它们的reference。
: 3，这些object的里面，你的business logic是在一个single threaded的环境里执行，
: 减少了race condition。
: 先想到这几点。
|
t*******e
发帖数: 684 | 20 这个看上去和akka差不多，都是message based concurrency model.
Camel, Zookeeper都有akka的实现了，估计spring integration也快有了。
【在 o**2 的大作中提到】
: 在概念上和thread pool有很大的区别，thread pool是一个独立的execution power，
: 你把代码提交给它去运行，然后得到结果。Fast Messenger通过message driven把
: execution power给内置到object里去了，变成了代码在object里面，它收到通知后就
: 自己找thread执行代码。
: 我刚好在最近的一篇blog里解释了这个区别：
: 英文：http://weblogs.java.net/blog/rexyoung/archive/2012/09/11/fast-messenger-high-level-concurrent-programming-model
: 中文：http://www.cnblogs.com/rexyoung/archive/2012/09/12/2681505.html
|
o**2
发帖数: 168 | 21 这个 post 已经放弃很久了，现在转战到 Programming 版了。 |
Y**G
发帖数: 1089 | 22 亚麻有个SWF - simple workflow framework
【在 z*******3 的大作中提到】
: 木有认真看你在做啥
: 不过从前面的人的说法看
: 貌似有两个东西你最好看看
: 一个是akka，akka有一个不好就是annotation支持比较差
: 如果你能做一个annotation支持的thread lib的话，还是有戏的
: 另外一个是work flow
: work flow engine有一个标准叫做bpm
: java的是jbpm，这个标准相对成熟
: 而且很多产品都已经可视化了，拖拖拽拽就搞定了
: 所以如果你想要继续
|
