上一篇我们大致的了解了几种聊天室的行为模式
最简单明了的推模式 几乎不需要任何多余的 语言来描述它的实现
这一篇我们看看如何实现拉模式更有效。
本图清晰的表现了 "拉"模式聊天室的行为。
并发多用户向数据池写数据
并发多用户从数据池读 书据
数据最好以时间为顺序储存在集合中
某时间向后的枚举查找将是最大的消耗。
聊天室进化 -女仆编年史神秘的原始社会
仍然参考我们神奇朴素的Asp3聊天室
53 Application.lock
54 Application("show5")=Application("show4") '一条新信息 驾到 第五条信息被淘汰
55 Application("show4")=Application("show3")
56 Application("show3")=Application("show2")
57 Application("show2")=Application("show")
58 Application("show")=NewMessage '其他所有的信息向前移 动一次给新的信息让个位置。
59 Application.UnLock
60 Response.Write Application ("show5")
61 Response.Write Application("show4") '由于 是postback 模式 必须输出历史n行数据
62 Response.Write Application ("show3")
63 Response.Write Application("show2")
64 Response.Write Application("show")
从线程安全角度来说 本来 response.write应该也在 application .lock 块中 或者分开两个lock块. 但是这里由于 response.write 在非cache模式下可能带来的时间延迟 作者煞费苦心的把他们从安全锁中移动出来.在 实际运行中 很可能出现丢话或者重复发言的状况
application究竟 被人做了些什么？ 没有边界 没有抽象包装的这个实现就好像原始共产主义 谁是谁的谁啊这都是！
私有制出现，奴隶社会 LOCK~ 这个女奴是我的~
翻译成c# 我们可以看到一个比较容易理解的逻辑 当然这个代码稍微有 所修改 两个锁很明确 很完美的把数据和线程排起了队伍
Code Snippet
class Channel
{
Queue<string> MessageQ = new Queue<string>();
public void Say(string message) //写信息
{
lock (MessageQ)
{
MessageQ.Enqueue(message);
while (MessageQ.Count > 5) // 删多余
{
MessageQ.Dequeue();
}
}
}
public string[] Listen() //u-28781 ?出所有
{
lock (MessageQ)
{
return MessageQ.ToArray();
}
}
}