anzhsoft的技术专栏

boost的mutex，condition_variable非常好用。但是在Linux上，boost实际上做的是对pthread_mutex_t和pthread_cond_t的一系列的封装。因此通过对原生态的POSIX 的mutex，cond的生成者，消费者的实现，我们可以再次体会boost带给我们的便利。

各种大型数据库所采用的锁的基本理论是一致的，但在具体实现上各有差别。 SQL Server更强调由系统来管理锁。在用户有SQL请求时，系统分析请求，自动在满足锁定条件和系统性能之间为数据库加上适当的锁，同时系统在运行期间常常自动进行优化处理，实行动态加锁。 SQLite采用粗放型的锁。当一个连接要写数据库，所有其它的连接被锁住，直到写连接结束了它的事务。SQLite有一个加锁表，来帮助不同的写数据库都能够在最后一刻再加锁，以保证最大的并发性。 MySQL数据库由于其自身架构的特点

Boost的互斥量，条件变量做了很好的封装，因此比“原生的”POSIX mutex，condition variables好用。然后我们会通过分析boost相关源码看一下boost linux是如何对pthread_mutex_t和pthread_cond_t进行的封装。最后给出生产者消费者问题的boost实现。

本文使用C++11实现无锁的stack。前几篇文章，我们讨论了如何使用mutex保护数据及使用使用condition variable在多线程中进行同步。然而，使用mutex将会导致一下问题 等待互斥锁会消耗宝贵的时间 — 有时候是很多时间。这种延迟会损害系统的scalability。尤其是在现在可用的core越多越多的情况下。 低优先级的线程可以获得互斥锁，因此阻碍需要同一互斥锁的高优先级线程。这个问题称为优先级倒置（priority inversion ）。 可能因为分配的时间

本周遇到了好几个core都很有典型性。在这里和大家分享下。相信有过Linux编程经验的人，肯定都遇到过。感觉周围人很多对core有天然的恐惧感，尤其对刚入行不久的同学来说。当然了，也有工作好几年看到core也束手无策的。今天就分析一下，core，其实大部分都是很容易解决的。如果一个core很难以复现，那么说明还是很复杂的，算是Corner case，可能需要很长时间，脑子里要有很好的运行时状态才可以（阅读源码，学习的是逻辑；将源码对应到运行时的状态，分析一些状态机的转换，再去分析可能会发生的情况）。相信前

高并发的情况下，锁是一个灾难；那么架构是如何做到无锁编程的？