多任务处理的问题

[zg351229063]

我今天碰到了多任务处理的问题，需要在软件架构上进行良好的设计才能实现。当我暂时没有想到好的方法。问题如下：

C对象是请求的发起者（比如，它发起了一个R请求）。S是请求的接收者（它接收到请求后可以自己处理也可以发给其它模块处理）。但此R请求比较复杂（可拆分为a,b,c三个子请求，且a,b,c中有些请求是异步的，不能直接返回）。

现在的设计目标是在代码逻辑清晰且连贯的前提下，尽量提供系统的吞吐量。请问该如何设计？

注：
1. 当S接收到请求后，需要处理a,b,c但a,b,c对于S来讲都是单独的事务之间没有什么联系（因为有些用户可能只会发送a请求给S，而不会同时携带b，c），这样S在什么时候返回就成了个问题（换句话说，S有什么简便的方式判断a，b，c都已经处理完成）。

2. 当C接收到R请求处理完成的消息后，还要进行一些后续处理。但如果C发出R请求后为了提高系统吞吐量没有等待返回的话，当接收到R请求处理完成的消息后，它可能已经不知道为什么发出此请求了。

[zg351229063]

怎么的了？

[DogWantToFly]

虽然不太清楚问题的具体情况，但是我觉得可以从分析，C与S的实际状态划分下手。
状态如果能与实际应用符合的话，应该可以解决楼主的问题吧

[gene639]

像tcp连接里的ack确认一样，可不可以让每个请求带上自己读一无二的标识字段，如果S非要等到a,b,c请求以至于确定了一个R请求处理结束了才能返回，可以把S的状态放在一个圆圈上面轮转，处理一个请求就改变状态。我随便说的，大概意思就是考虑：在请求里加上标识字段(a,b,c? a1,b1,c1? )及S的状态， C怎么处理它所发送请求并确定是不是R请求，就可以通过判断标识是不是a,b或c以及当前s的状态

[cxyOOOO]

proactor ?

[super_admi]

我怎么觉得楼主说的这东西，咋特别像我们公司的UIF框架啊？不过我们公司的UIF框架，我觉得缺陷比较多。

我的建议如下：

1.关于请求的发起者C，不用考虑它。一般来说，只要设置一个监听就能搞定。但是这里要注意多路并发的情况。

2.每次监听到一个请求时，如果此请求需要自己处理，则处理之，否则，创建一个新的线程（咋感觉像SOCKET连接？），启动一个请求处理过程。

3.如果需要判断请求处理是否已经完结，建议使用哈希表，建立一个请求与标志的对应关系（如果请求与处理过程及标志的对应关系是固定的，也可以不用这么麻烦）。

[super_admi]

上面说的是多个请求相互之间无关的情况。如果多个请求之间是有序的，则建议使用消息栈来保存请求标志。