写socket网络通讯Agenda时遇到的几个坑

Agenda是软院大一实训项目，据说年年都是这个……

1.server与UI之间的通信

写socket的时候决定了采用Client只管收发信息的那种，server跟UI共享两个stringstream，一个是输入到UI的，一个是UI的输出，大致上是Client跟server轮流收发信息。问题出现在server接受到Client的信息后，调用UI处理Client的指令。但是原本UI的设计是先接受一条指令(如l)，然后在屏幕上打印这个命令的参数提示，再让用户输入所需的参数完成这条指令。于是在等待输入参数的时候没有办法也不能返回(不然就要大改改成保存上一次的状态，这样太不科学了)，没办法回到server那里去继续收发。此时其实也可以把UI改成要求用户一次性输入一条完整的命令，结果还是选择了用多线程来解决……开了一个UI线程，一个server线程，两个线程轮流工作，server把收到的东西放到stringstream里，UI取出命令或参数处理，产生输出给server，server再发出去。

2.多线程

关于多线程，就一个字，坑。一开始两个线程都是不停的，我的处理方法是写一个patient_stream类，里面有一个stringstream成员，当需要从stream中取出东西的时候，会查看stream是否为空，非空则gao之，空的话就等待一会儿再去查看。结果出现了奇怪的BUG，学了gdb多线程调试的皮毛，没调出来，又给patient_stream对象加了互斥锁，跪了，因为在等待输入的时候会出现一个线程拿着锁不放23333。后来才想到了因为两个线程是轮流工作的，直接用一把互斥锁弄一下就行了。

用mutex的时候看网上说“如果调用pthread_mutex_lock()时mutex已经被其他线程锁住，那么这个线程会阻塞并等待这个互斥锁被释放”，大喜，那么就是说会排队等着获得mutex吧，我想。

我太天真了。

假如线程A先获得了一个mutex，线程B又跑去lock这个mutex，此时线程B确实会停下来，可是如果线程Aunlock了这个mutex以后立刻调用lock的话，获得mutex的就会是A而不是B，pthread_mutex_lock()并不遵循“先到先得”的原则，而是“谁快就是谁的”。B刚发现mutex被unlock了，A又把mutex抢走了。解决办法是unlock以后先延时一下下再去lock。话说如果线程更多一点的话怎么破……用mutex实现一个atomic的队列？

另外还有一个小坑，在我的写法(两个线程轮流工作)下，如果某个线程lock以后到unlock做的事情太少以致于比另一个线程unlock后到lock还快的话，这个线程也可以连续占有mutex，这种情况需要在lock以后延时足够另一个线程unlock后到lock的时间。

3.stringstream的eof

stringstream在经过">>"运算符变成empty后会置eofbit，而eof时再次">>"统统fail(">>"取出的字符串都会是空的)，即使"<<"或者str("...")插入内容也不能改变，只能clear()