（总结）高并发消息队列常用通知机制，队列机制

（总结）高并发消息队列常用通知机制，队列机制

最近在研究一个高性能的无锁共享内存消息队列，使用的fifo来通知。结合之前《基于管道通知的百万并发长连接server模型》文章，这里总结一下常用的通知机制。

常用的通知机制中比较典型的有以下几种：

1、signal

这种机制下，我们向被通知进程发送一个特殊的signal（比如SIGUSR1），这样正在睡眠的读进程就会被信号中断，然后醒来。

该方法的优点是：读进程不需要监听一个额外的eventfd，适合一些不方便使用eventfd的场景；另外，用户可以选择是使用实时信号（SIGRTMIN+1），还是使用非实时信号（SIGUSR1）。

该方法的缺点是：通知不实时。因为信号的检查只有在中断返回的时候才会进行，这个时间跟操作系统的HZ、jiffies有关。

2、socket

这种机制下，写进程往socket（domain socket）写一个字符，然后读进程通过epoll得到数据到达的通知。

3、fifo

这种机制跟socket类似，写进程往fifo中写一个字符，然后读进程通过epoll得到数据到达的通知。

4、pipe

跟2、3差不多。

5、eventfd/signalfd

跟前面差不多，不过是内核帮我们事先fifo、signal通知，只有比较新的内核版本才支持。这种方式存在的问题是需要在不同进程间传递句柄，非fork方式实现比较复杂。

上面这几种方式的共性是都需要陷入内核，被通知进程只有在内核态才能接收通知，对于处理性能要求高的场景，应该少用通知。所以，当然就看业务场景发送通知的开销是不是很大了。如果请求量很大，读进程一直忙于处理，不会频繁触发通知，那就很合适了。

WM_PAINT和WM_TIMER都是优先级不同的，WM_TIMER优先级最低，只有队列里没有其他消息才会执行，WM_PAINT则较高

从窗口创建开始说：
CreateWindowEx，这个会向窗口例程直接投递WM_CREATE，而不进入消息队列，其他消息则是比较正常的经过消息队列，然后通过GetMessage和DispatchMessage取消息和分发到相应例程，直到取到WM_QUITE就结束消息循环。
对于按键和鼠标消息则是先进入系统消息队列，然后系统队列会分发到相应的线程消息队列
记住，消息队列是线程所有，并非窗口所有和进程所有，当然，系统队列例外。
 

我依稀记得曾经看过一篇章，说Borland当初的Turbo Pascal主要就是一个牛牛用汇编写出来的。呵呵，如果有人给GCC写个类似VC的界面我举双手双脚赞成，免费帮他测试:-) 有时我在想，Borland当初开发Delphi的时候不用Pascal而用C++的话，现在开发工具的市场份额会是个什么格局?(本人绝对没有瞧不起Pascal的意思，事实上我的第一门语言就是Pascal，只是因为图书馆里Pascal的书被人借光了才自学了C)
如果我给Gcc写了个界面，当然还是GCC。用过GCC的人从来不会说GCC比不上Visual C++，两者实在没有办法比，不在一个数量级上。GCC是个强大的编译器，支持N种硬件平台和官方的软件标准，同时也引入了很多软件开发者急需的好特性。大多数优良的库，罕有不能在GCC上编译通过的。嘻嘻，有为GCC做广告之嫌？
至于GCC的商业化，我就看到过一些卖硬件产品的公司，它们附带的编译器就是GCC或者其变种。再说了，大量大型的软件都可以用GCC编译出来的，从稳定上讲我想不会比Visual C++差吧。事实上，我用Visual C++的时候就遇到过所谓的Internal Error，而我用GCC，就从来没遇到过这种莫名其妙的内部错误的抱怨。我想，GCC绝对有商业软件的潜质，呵呵，就是在可视化方面比不上Visual C++，虽说也有一些GCC的图形前端。

机遇是从耐心中产生的，越有耐心，就越有机遇。
名言啊名言，我有耐心啊，机遇快来吧，呵呵。
大家还是埋头苦干吧，别真的机遇来了你还没有准备好，呵呵～～

如果你是从MFC入手的，或者是从VC入手的，那么要做出一个真正的能应用个人领域的通用软件，就会走非常多的弯路。
怪了去了，怎么从MFC或者VB入手就会走非常多的弯路呢？从MFC或者VB里调用Win32 API很直接，尤其在Visual C++ MFC里。《箴言》很看重底层，Win32 API难道还不够底层吗？难道非要在汇编一级才可以写出真正的通用软件吗？那我干脆去给CPU写微码去了，呵呵～～～。VB我用的很少，就不说了。至于MFC，如果你真正弄懂了MFC那么你对于Windows的各个方面几乎就全部精通了(当然，我是指Windows内核外用户空间的
东东)。
计算机这个东西不管是硬件还是软件，层次很重要。开发很重要的一个方面就是要弄明白你自己需要在什么层次上做东西。一个用java写中间件的开发人员，有多大必要去精通系统底层的东西呢？我想如果你不立足于自己的层次做东西，而胡乱搞跨层的东西，结果可能就是出力而不讨好了。自己研究研究还行，如果在工作中还是这样层次不清楚的话，呵呵，就很危险了。
当然，我没有让大家不去钻研，但我想最好还是找个前辈请教，根据自己的兴趣制定自己的学习计划。人的精力毕竟有限，我们要把有限的精力投入为人民服务之中去嘛，可不要浪费了哟，呵呵。

只想混口饭吃，找个工作，可能教你成为MFC的高手之类的书对你就足够了。
我却认为只有熟练的使用某种语言是每个程序员必备的。其他的一些能力对于不同的开发方向应该是不同的。比如《箴言》认为第二阶段是精通某种平台的接口(比如Win32 API)。然而，很多做高层开发的同志，往往不太接触这些底层的API，因为在他下面，操作系统上面已经叠加了很多的层次了。比如，如果你用Java在Win32上面编程，几乎不需要和系统API打交道。这其实也体现了软件分层的思想：每一层只负责自己的职能，只和自己相邻的层通讯。
1. “软件行业将很快成熟，门槛越来越高。”没错，随着软件行业的发展，想成为成功的......余下全文>>