首页
学习
活动
专区
工具
TVP
发布
精选内容/技术社群/优惠产品,尽在小程序
立即前往
  • 您找到你想要的搜索结果了吗?
    是的
    没有找到

    c++ 跨平台线程同步对象那些事儿——基于 ace

    ACE (Adaptive Communication Environment) 是早年间很火的一个 c++ 开源通讯框架,当时 c++ 的库比较少,以至于谈 c++ 网络通讯就绕不开 ACE,随着后来 boost::asio / libevent / libev … 等专门解决通讯框架的库像雨后春笋一样冒出来,ACE 就渐渐式微了。特别是它虽然号称是通讯框架,实则把各个平台的基础设施都封装了一个遍,导致想用其中一个部分,也牵一发而动全身的引入了一堆其它的不相关的部分,虽然用起来很爽,但是耦合度太强,学习曲线过于陡峭,以至于坊间流传一种说法:ACE 适合学习,不适合快速上手做项目。所以后来也就慢慢淡出了人们的视线,不过对于一个真的把它拿来学习的人来说,它的一些设计思想还是不错的,今天就以线程同步对象为例,说一下“史上最全”的 ACE 是怎么封装的,感兴趣的同学可以和标准库、boost 或任意什么跨平台库做个对比,看看它是否当得起这个称呼。

    01

    万字图解| 深入揭秘Golang锁结构:Mutex(上)

    Golang的Mutex算是在日常开发中最常见的组件了,并且关于锁的知识也是面试官最喜欢问的。    曾经在一次腾讯面试中,被面试官问得体无完肤。    虽然Golang Mutex只有短短的200多行,但是已经是一个极其丰富、精炼的组件,有极其复杂的状态控制。我已经看过很多次Mutex的源码,但是总是过段时间就会又处于懵逼状态,不得其道。分析下来,猜测是缺少“历史背景”,一上来就看到的是已经经过好几轮优化的代码,但是不清楚这么优化的背景,同时也缺少一些场景,就会导致无法理解一些设计。    其实如果我们去追溯 Mutex 的演进历史,会发现,Mutex最开始是一个非常简单的实现,简单到难以置信的地步,是Go开发者们经过了好几轮的优化才变成了现在这么一个非常复杂的数据结构,这是一个逐步完善的过程。    于是我想如果我们是设计者,我们会怎么去设计去优化一个锁的实现呢?    下面我将结合我曾经的腾讯面试经历 加上 代入“设计者”的角度出发,结合Mutex 的演进历史,去分析如何设计一个功能完备的锁。希望经过本文的分析,你也可以从零设计出属于你的「Mutex」。    友情提醒:文章很长,但是绝对值得一读。

    03
    领券