进度条和多线程,解耦GUI和逻辑 - 哪种设计模式最好？

我正在寻找适合我的应用程序设计的设计模式.

我的应用程序处理大量数据并生成一些图表.数据处理(从文件中获取,CPU密集型计算)和图形操作(绘图,更新)在单独的线程中完成.

图表可以滚动 - 在这种情况下,需要处理新的数据部分.因为图形上可以有多个系列,所以可以生成多个线程(每个系列有两个线程,一个用于数据集更新,一个用于图形更新).

我不想创建多个进度条.相反,我希望有一个单一的进度条来告知全球进展.目前我可以想到MVC和Observer/Observable,但它有点模糊:)也许有人可以指出我正确的方向,谢谢.

我曾经花了一周时间试图在一个非常复杂的算法上创建一个平滑,非打嗝的进度条.

该算法有6个不同的步骤.每个步骤的时序特征严重依赖于A)正在处理的基础数据,不仅仅是数据的"数量",而且还有数据的"类型"和B)随着cpus数量的增加,两个步骤的得分非常好,在2个线程中运行2个步骤,并且2个步骤实际上是单线程的.

有效的数据混合对每个步骤的执行时间的影响远大于核心的数量.

最终解决它的解决方案非常简单.我制作了6个分析数据集的函数,并试图预测每个分析步骤的实际运行时间.每个函数的启发式分析了分析中的数据集和cpus的数量.基于我自己的4核机器的运行时数据,每个函数基本上都返回了我的机器上预计需要的毫秒数.

f1(..)+ f2(..)+ f3(..)+ f4(..)+ f5(..)+ f6(..)=总运行时间,以毫秒为单位

现在提供此信息,您可以有效地了解每个步骤应执行的总执行时间的百分比.现在,如果你说step1应该占用40%的执行时间,你基本上需要找出如何从该算法中发出40个1%的事件.假设for循环正在处理100,000个项目,您可能会这样做:

for (int i = 0; i < numItems; i++){
     if (i % (numItems / percentageOfTotalForThisStep) == 0) emitProgressEvent();
     .. do the actual processing ..
}

这个算法为我们提供了一个完美无瑕的顺畅进度条.您的实现技术可以在进度条中使用不同形式的缩放和功能,但思考问题的基本方法是相同的.

是的,启发式参考数字在我的机器上得到解决并不重要 - 唯一真正的问题是如果你想在不同的机器上运行时更改数字.但你仍然知道比率(这是唯一非常重要的事情),所以你可以看到本地硬件的运行方式与我的不同.

现在,平均SO读者可能想知道为什么有人会花一个星期来制定一个平稳的进度条.该销售人员要求该功能,我相信他在销售会议中使用它来获得合同.有钱能使鬼推磨 ;)