Lockless Programming Considerations for Xbox 360 and Microsoft Windows
dx sdk里面的technical article的文章，比较赞。
Programming with locks
用lock做多线程编程是很直接的一个事情。
一个getlock(); 一个releaseLock();就可以保证中间代码执行是线程安全的。
实际情况中比较有问题的还是等待锁时候所花费的时间。
这篇文章也正是讨论这种减少锁等待的情况。
Atomic operation
不可分割的操作，在这个operation在一个线程中执行的过程中，其他线程没法看到这个操作。
像ps3和xbox360都提供了很多这种atomic operations。
其他的一些操作就需要think in hardware or low level
比如 i++; 展成汇编是read->add->write操作，这个不属于atomic operation
简而言之，有些指令是天然atomic的，放心用，有些是操作系统提供的atomic operation（像incre什么的），其他的如果有需要就用lock吧。
Reordering:
仍旧是需要think in hardware or low level，现代编译器和处理器都会在合适的情况下做重排序。
像编译器会对没有数据依赖性的代码重新排序来增加并行性---这时候单纯查看c++代码就无法看出问题所在
xbox360 processor没法保证数据写到或者读取自L2 cache的顺序---这时候看asm也无法看出问题所在。
解决方案包括：
memory barrier：可以保持对于memory读写的正确顺序。
使用像_ReadWriteBarrier这样的指令来让编译器保证执行顺序（防止重排序，把barrier后面的东西弄到前面了，这也是barrier的定义呃）
使用像lwsync和sync这样的指令来保证cpu在barrier上的特性（后面的不会跑到前面去，也就是说读写cache行为不会自作主张的给出我们不想要的优化重排序）
这里是sync是重口味，lwsync（light weight）是轻口味，要快一些。
还有像interlockxxx这样的函数，禁止compilor重排序是肯定的，但是cpu不一定了（windows上禁止，xbox360不禁止），所以使用过程中仍旧要注意cpu重排序的情况。
volatile
c++规定volatile不能被delay，不能被cache，读写不能出现顺序互换的情况。
但是对于nonvolatile和volatile之间的顺序就无法保证了（compilor和cpu都无法保证）
一些lockfree的实例
这个估计是很多了，lockfree pipe是其中一个，当线程关系是producer&consumer的时候可以这样做。
所以对于多线程之间的模型分析，基于多线程和底层知识进而找出合适的lockfree解决方案，是获得高效正确的多线程程序的法宝。
一些数据：这些是粗略估计，不同的上下文和硬件当时情况，结果很不一样的。
xbox360：
mutex的消耗太惊人了，是critical section的5倍啊。
windows
呃，没法总结啊，太杂了，但是依稀记得以前看得多线程书是挺好的，提供了理论基础之后剩下的就是具体情况的记忆了。