恶狼战役：getTime() 的容错性问题

[老范]

在代码中， 之前发现 debug 那个 getTime () 函数，有时候系统会崩溃。 由于崩溃情况较少，大家没有进一步处理。

这次我重构发现erlang 还是需要显式的调用ets:delete 掉时钟表，并做了修改。 开始没问题。 一切正常。 但是当我打开对于战场列表
debug 功能后， 系统就崩溃了。

发现由于debug 战场列表， 对于战斗指令消息处理的速度大大降低。造成第一个时钟节拍后，开始处理指令消息的过程中，时钟过了5个节拍，然后认为
战斗结束了，就把 时钟表删掉了。

这时还有大量堆积的命令消息没有处理，当系统处理这些命令消息时，去读时钟表。 系统就垮了。 我感觉书上说的可能也没错， 确实进程死掉后，其创建的
ets 表会消亡。 但是可能是要过较长的时间才会。 因此原来不删时钟表的代码偶尔会崩溃。 而现在直接删时钟表的代码必然崩溃。

对于getTime 做了try 处理，提高容错性。 解决了这个问题。

[Zoom.Quiet]

2009/7/3 老范 <fanyu...@gmail.com>:

> 在代码中， 之前发现 debug 那个 getTime ()  函数，有时候系统会崩溃。 由于崩溃情况较少，大家没有进一步处理。
>

嗯嗯嗯,其实,先写个期望大家怎么调用的伪代码,
用故事叙述一下,整个战场的逻辑,
就容易看出哪儿应该有问题了,,,,

现在,就只能多测试了,,,

> 这次我重构发现erlang 还是需要显式的调用ets:delete 掉时钟表，并做了修改。 开始没问题。 一切正常。 但是当我打开对于战场列表
> debug 功能后， 系统就崩溃了。
>
> 发现由于debug 战场列表， 对于战斗指令消息处理的速度大大降低。造成第一个时钟节拍后，开始处理指令消息的过程中，时钟过了5个节拍，然后认为
> 战斗结束了，就把 时钟表删掉了。
>
> 这时还有大量堆积的命令消息没有处理，当系统处理这些命令消息时，去读时钟表。 系统就垮了。 我感觉书上说的可能也没错， 确实进程死掉后，其创建的
> ets 表会消亡。 但是可能是要过较长的时间才会。 因此原来不删时钟表的代码偶尔会崩溃。 而现在直接删时钟表的代码必然崩溃。
>
> 对于getTime 做了try 处理，提高容错性。 解决了这个问题。

--
http://zoomquiet.org 人生苦短,Pythonic!-)
Time is unimportant, only life important!

[老范]

这个问题的诊断和处理，让我越发 “并行计算”  的复杂度有了深刻的认识。 在顺序环境中，这都是没必要考虑的问题。

并行环境中， 时序的处理非常重要。 都要仔细琢磨。



Regards

老范

2009/7/4 Zoom.Quiet <zoom....@gmail.com>

[Max Fung]

下载r190

从源程序上，都太过于依赖ets。
例如：

worldclock.erl
battle_timer 就可以不使用 ets
在start的时候，直接出个线程就好了，
请见附件

【注意，我只是举个例子来写，没有完成worldclock】

现在程序中，很多的ets都可以不要的。
ets有它使用的地方，如果只是作为单纯的变量传递，请尽量不要使用。
在erlang一切都是process ，忘了java，忘了c，忘了……吧
尽量用erlang的世界观去解决问题。

2009/7/3 老范 <fanyu...@gmail.com>

[Max Fung]

另外，时间控制，强烈推荐使用 timer 模块，具体使用查api吧 :)

2009/7/4 Max Fung <honeygi...@gmail.com>

[老范]

感谢Max 的意见。 首先我自己也对于使用ets 做数据传递觉得有点那个。 但是没想到好办法。

看了Max 的代码和邮件， 觉得有些启发。 但是在erlbattle 的具体场景中可能还是有些问题需要进一步解决。

1.  这个worldclock 和timer 不是一回事。 他不是一个定时器。准确来讲是一个节拍器。 表明战场一个一个节拍的往下走。未来系统进一步优化的时候，希望在不同处理能力的机器上， 在每个节拍给决策程序提供的“计算周期” 是一样的。

2. Max 程序中用消息方式从worldclock 中提取出当前时间。
这样的话，如果需要查询时间的“决策进程” 频繁，恶意的向worldclock 发时间请求消息，会造成时间没法往下走的情况，也可以堵塞对手查询时间的功能。让对手不能及时知道当前时间。

现在使用的时钟表， 战场表， 双方下一步指令队列表 都有这种并行查询的需求。用消息来问恐怕有点不妥。


Regards

老范

2009/7/4 Max Fung <honeygi...@gmail.com>

[Zoom.Quiet]

2009/7/4 老范 <fanyu...@gmail.com>:

> 1.  这个worldclock 和timer 不是一回事。 他不是一个定时器。准确来讲是一个节拍器。
> 表明战场一个一个节拍的往下走。未来系统进一步优化的时候，希望在不同处理能力的机器上， 在每个节拍给决策程序提供的“计算周期” 是一样的。
>

是也乎,而且这个节拍器是可以调节的,比如说,慢到 3秒钟一次,以便可以明白的看到每次双方的出击;
也可能 2秒一次,以便加速自动化测试...
更加重要的是,将来为了分布式运行,必须根据网络状态,自动进行同步降速,以便双方的EB世界时间是同步的...

> 2. Max 程序中用消息方式从worldclock 中提取出当前时间。
> 这样的话，如果需要查询时间的“决策进程” 频繁，恶意的向worldclock
> 发时间请求消息，会造成时间没法往下走的情况，也可以堵塞对手查询时间的功能。让对手不能及时知道当前时间。
>
> 现在使用的时钟表， 战场表， 双方下一步指令队列表 都有这种并行查询的需求。用消息来问恐怕有点不妥。
>

嗯嗯嗯,核心原理就是:
- 时钟和战场 在EB 中应该是中立的,不可影响的:
+ 时钟就是授时,统一行动节奏
+ 战场就是记录进程,核对各双血状态
- 所以,得反过来?
+ 统一向双方定期推信息
+ 或是向一个消息总线通报信息,由双方战士决定何时查询?

>
> Regards
>
> 老范
>
>
>
>
>
> 2009/7/4 Max Fung <honeygi...@gmail.com>
>>
>> 下载r190
>>
>> 从源程序上，都太过于依赖ets。
>> 例如：
>>
>> worldclock.erl
>> battle_timer 就可以不使用 ets
>> 在start的时候，直接出个线程就好了，
>> 请见附件
>>
>> 【注意，我只是举个例子来写，没有完成worldclock】
>>
>> 现在程序中，很多的ets都可以不要的。
>> ets有它使用的地方，如果只是作为单纯的变量传递，请尽量不要使用。
>> 在erlang一切都是process ，忘了java，忘了c，忘了……吧
>> 尽量用erlang的世界观去解决问题。
>>
>>
>>
>> 2009/7/3 老范 <fanyu...@gmail.com>
>>>
>>> 在代码中， 之前发现 debug 那个 getTime ()  函数，有时候系统会崩溃。 由于崩溃情况较少，大家没有进一步处理。
>>>
>>> 这次我重构发现erlang 还是需要显式的调用ets:delete 掉时钟表，并做了修改。 开始没问题。 一切正常。 但是当我打开对于战场列表
>>> debug 功能后， 系统就崩溃了。
>>>
>>> 发现由于debug 战场列表， 对于战斗指令消息处理的速度大大降低。造成第一个时钟节拍后，开始处理指令消息的过程中，时钟过了5个节拍，然后认为
>>> 战斗结束了，就把 时钟表删掉了。
>>>
>>> 这时还有大量堆积的命令消息没有处理，当系统处理这些命令消息时，去读时钟表。 系统就垮了。 我感觉书上说的可能也没错， 确实进程死掉后，其创建的
>>> ets 表会消亡。 但是可能是要过较长的时间才会。 因此原来不删时钟表的代码偶尔会崩溃。 而现在直接删时钟表的代码必然崩溃。
>>>
>>> 对于getTime 做了try 处理，提高容错性。 解决了这个问题。
>
>

--
http://zoomquiet.org 人生苦短,Pythonic!-)
过程改进乃是催生可促生靠谱的人的组织! (PE keeps evolving organizations which promoting
people be good!)