加锁、解锁(同步/互斥)是多线程中非常基本的操作，但我却看到不少的代码对它们处理的很不好。简单说来有三类问题，一是加锁范围太大，虽然避免了逻辑错误，但锁了不该锁的东西，难免降低程序的效率；二是该锁的不锁，导致各种莫名其妙的错误；三是加锁方式不合适，该用临界区的用内核对象等，也会降低程序的效率。要正确

昨天整理家当时想起来的，从最早开始写到现在已经将近10年了，最后一次修改也是7年前的事了，发上来做个纪念吧。很多地方实现的很难看，但对初学者应该还有些参考价值。昨天稍微改了一下，能在vs2005下编译通过了，不过由于当时赶“时髦”，用了direct sound，但现在我机器上没有directx的库了

本来不是什么大问题，不过鉴于我对.net的熟悉程度，和半天的时间，还是记录一下。另外blog也好久没更新了，顺便刷一篇。本问题涉及到两个模块: a.dll: c++编写，本机代码；b.exe: c#编写，托管代码。b调用a，运行时有点问题，但不确定是哪边的原因，故开始debug。但发现，不管是从a启

最早是在下面的程序中发现的问题：// a.cppstruct foo{    void bar(){printf("foo::bar in a.cpp\n");}};void testa(){  foo f;  f.bar();}// b.cppstruct foo{    vo

原文链接0. 什么是副作用（side effects）C99定义如下：Accessing a volatile object, modifying an object, modifying a file, or calling a function that does any of those op

这两天有点焦头烂额, 我们这边运行的好好的程序, 到了测试的机器上就不能启动(是根本运行不了, 而不是运行出错), 弄得我异常郁闷. 经过了一番摸索, 发现和winxp、win2003中为解决dll hell而引入的manifest机制有关系. 而以前我们用vs2003开发, 它并没有强制程序使用m

与《windows核心编程》上的那个相比最大的优势是体积小, 它只有四个字节(《windows核心编程》上的那个至少是它的10倍), 如果你有大量对象需要进行单写多读访问的话, 它会比较适用. 缺点是它在加锁时使用的等待函数是Sleep, 如果访问冲突很多的话, 效率比较低. 代码如下, 很简单,

论坛上经常有人问某个结构体的大小为什么与他预计的不一致, 对特定问题，我肯定能回答出来; 但要从总体上说出个子丑寅卯, 我就不行了. 今日闲来无事, 特地研究了一下, 总算将sizeof的计算方法大概梳理清楚了.字节对齐每种cpu都有其特定的字长, 如目前最常见的32位cpu, 其字长就是32位(4

毫无疑问, 引用计数是一种非常有效的动态控制对象生命周期的机制. 我们最熟悉的引用计数实现可能就要数COM的AddRef和Release了. 但这种机制也有明显的缺点, 那就是无法实现对对象死亡时间的精确控制: 调用Release后, 就失去了对对象的控制, 虽然对象可能会被立即杀掉, 但我们无法保

本文将不定期更新，记录个人所犯之常识性错误。数组参数的体积（2006.10.08）void foo( char bar[100] ) { printf( "%d ", sizeof(bar) ); }一直认为输出应该是100, 但实际却是4(即sizeof(char*))