Lockless Programming Considerations for Xbox 360 a

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：

• lwsync was measured as taking 33-48 cycles.
• InterlockedIncrement was measured as taking 225-260 cycles.
• Acquiring or releasing a critical section was measured as taking about 345 cycles.
• Acquiring or releasing a mutex was measured as taking about 2350 cycles. 

  mutex的消耗太惊人了，是critical section的5倍啊。

  windows

• MemoryBarrier was measured as taking 20-90 cycles.
• InterlockedIncrement was measured as taking 36-90 cycles.
• Acquiring or releasing a critical section was measured as taking 40-100 cycles.
• Acquiring or releasing a mutex was measured as taking about 750-2500 cycles.  

  ---

  呃，没法总结啊，太杂了，但是依稀记得以前看得多线程书是挺好的，提供了理论基础之后剩下的就是具体情况的记忆了。