浅析条件变量
本篇博客会深入分析条件变量实现来理解两个问题:
- 为什么条件变量要配合锁来使用 — 信号丢失问题
- 为什么条件变量需要用while循环来判断条件,而不是if — 虚假唤醒(spurious wakeup)问题
这两个问题不仅是C会遇到,所有语言的封装几乎都不可避免
先区分一下条件和条件变量,条件是指常用情况下,signal线程修改的值,使得cond_wait判断该值后不再阻塞
本篇博客会深入分析条件变量实现来理解两个问题:
这两个问题不仅是C会遇到,所有语言的封装几乎都不可避免
先区分一下条件和条件变量,条件是指常用情况下,signal线程修改的值,使得cond_wait判断该值后不再阻塞
一直以来用的友言第三方评论系统倒闭了,现在连官方网站都打不开了。
所有的评论数据全部丢失,很伤。那我宁愿用开源的评论系统了,例如isso。
下面记录一下isso的使用方法(isso-0.11.1版本)。
1 | 安装pip,sqlite |
做分布式事务的时候用到了存储过程加事务,由于忘记在存储过程中捕获异常rollback,导致了死锁
不过我select ... for update锁的是A表,实际线上却是B表被锁死
sql一块之前理解不深入,debug的过程重新复习一下
简化逻辑重现核心bug
23个设计模式中,大部分多写代码都是可以直接领悟到的。
但是访问者模式不是。一个原因是这个模式的实际应用场景在后端开发流程中特别难遇到(一般用于解决固定问题,游戏开发的复杂逻辑应该能经常遇到),
另外一个原因是这个模式的实现有点绕。
这一篇并不包含实践环节,因为我并没有实际遇到这样的需求,因此本篇只能记录下学习过程了。
习惯了golang的net/http/pprof的便利,c++的性能分析就显得繁琐了一点。
不过大致上还是一致的。
1 | centos: |
两个因素想做开源项目:
1 主导开发中间件系统的心愿已经达成,虽然中间磕磕碰碰的踩了很多坑。
但毕竟最终结果是好的。
唯一的遗憾就是没有开源了。
2 之前做了一些小网站,也累积了不少用户,但是对技术的磨练还是太少了。
特别是用户的增长出现瓶颈以后,架构和细节已经没有必要在优化了。这就让人产生了惰性。
认真做一个开源项目,会有bug issue和功能的issue。会有人去推动你不断探究。
我认为这会收获巨大。
具体项目没想好,可能是基础库(偏网络高并发?又一个轮子?),也可能是比较擅长的存储系统。
有些博文会把对象分为类模式和对象模式,在我看来这两种模式是可以相互转化的。类模式主要强调类的继承决定结构或者行为,是通过继承的延迟到子类去实现,来完成模式。而对象模式则主要强调对象的关联来完成模式(关联一个接口用桥接模式完成继承,关联一个对象用适配器模式完成调用)。所以所有的类模式都可以转化为对象模式,而对象模式则不一定可以转化为类模式。
对写golang的同学来说这一点很容易理解,因为golang只有关联没有继承。想要通过继承来延迟到子类去实现,实际上子类是通过关联一个实现了某个接口的对象以及父类,然后把关联的过程封装在创建过程中。这样不同的子类通过动态的组合不同的对象来完成继承。(实际就是桥接模式)
我认为,控制反转和模版模式以及框架的概念是类似的,而控制正转类同于策略模式,库。
反转的是依赖关系,对框架代码来说,实现的就是模版模式。使用框架的代码,其实被反转调用了。而库则是主动去调用的,是一种策略模式。
因为控制反转是一种设计模式,因此所有语言都存在。
例如C,JS是以回调函数实现。而Python作为一种动态语言,这方面的支持更为强大。
对于OOP的静态语言(Cpp,Java,Golang等等)来说,通过继承的实现更为自然(Golang通过桥接模式变相实现)。