Weakyon Blog
0%

发表于 更新于 分类于 本文字数： 62k 阅读时长 ≈ 56 分钟

在维护网络库时，总能遇到一些没太大用处，但是很有意思的小知识，细细碎碎又不成体系，记录一下

异步的epoll使用

  • 2015.5.22整理：

    epoll下LT和ET的处理都是大致相同的

    • LT模式

      读buff有数据 / 写buff有空间，就触发

    • ET模式

      读buff有数据，且数据减少或调用epoll_mod时 / 写 buff 空间增加或调用epoll_mod时，才触发

    LT模式例子:

    https://www.cnblogs.com/lojunren/p/3856290.html

    https://github.com/hurley25/ANet

    https://juejin.im/post/5ab3c5acf265da2380598efa

    https://www.zhihu.com/question/22840801

    https://blog.codingnow.com/2012/04/mread.html

    在ET模式中，需要主动把数据读完或者写满：

    • 读处理是一直read

      返回-1，检查errno，如果是EAGAIN那么不再读（缓冲区读完），如果是其他那么说明连接出错，进行报错然后也不再读。

      返回0，说明对端关闭

      返回大于0，成功读到数据

    • 写处理是一直write，直到数据写完

      返回-1，检查errno，如果是EAGAIN那么不再写（缓冲区写完），如果是其他那么说明连接出错，进行报错然后也不再写。

      返回大于0，成功写数据

在使用tcp时，内核的tcp上存在读写缓冲区，上层app通过这个缓冲区来和实际的网络进行通信

app <=> 内核tcp <=> network

阅读全文 »

发表于 更新于 分类于 ， 本文字数： 9.5k 阅读时长 ≈ 9 分钟

本文主要讲述了Borg论文中引用的基于机会成本的E-PVM算法

这个算法的缺点（大型任务难以调度）是在我的场景下是可接受的

对Borg来说，任务实际是一个任务组，亲和需求的任务组需要特别多的资源

而在我的调度问题中，大型任务是很少的，因为我的调度器不提供任务组的概念，由业务来解耦任务组

我尝试理解该算法后做一些优化，然后通过模拟器模拟和分集群测试来查看是否可以提升资源利用率

阅读全文 »

发表于 更新于 分类于 ， 本文字数： 23k 阅读时长 ≈ 21 分钟

Bistro

《Bistro: Scheduling Data-Parallel Jobs Against Live Production Systems》

facebook2015年论文，用于解决离在线混部时，约束离线任务运行在指定资源范围的问题

  • 提出了一种基于树模型的资源调度问题

    例如叶子节点是数据库卷，上面的父节点是主机，机架等等

    在任务退出时，对影响到的叶子节点以及父节点（直到根节点）进行调度，来避免全部资源池的调度太过耗费性能

Bistro在架构上允许对树的独立资源的根节点，哈希或者按位置进行分区，从而进行并行调度和分布式调度

阅读全文 »

发表于 更新于 分类于 本文字数： 35k 阅读时长 ≈ 32 分钟

我在整理tars和taf的协程逻辑的时候，也实现了一个纯净版的协程框架以便于理解

是基于我6年前编写的网络框架sheep_cpp修改的，虽然当年在魅族也是生产环境的网络框架，但是以我目前的经验来看，还是有很多不足的地方

仅作为演示协程实现的代码应该还是绰绰有余的，协程和协程套件的单元测试全部正常运行，用例在https://github.com/tedcy/sheep_cpp/blob/master/test/coroutine/coroutinue_test.cpp

网络框架

网络框架部分最大的问题还是单线程模型了，成熟的框架都是网络线程和工作线程分离的

阅读全文 »

发表于 更新于 分类于 本文字数： 3.7k 阅读时长 ≈ 3 分钟

最近大概间隔1个月，我在使用定时任务类时遇到了两次析构过程中的 bug

这两个 bug 出现在我用别人写的定时任务类时，这两个bug的区别是一个是组合使用的，另一个是继承使用的

由于coredump的堆栈都不在正常的位置，因此这两个bug都花费了我平均一整天的大量时间去定位

另外有个基于协程的定时任务类，这个类不仅只是使用，甚至都是我实现的，尽管 bug 还未发生，我仔细看了下居然也存在类似的问题

因此，我觉得我有必要总结这个问题，避免再次在相同的问题上耗费太多时间，毕竟多线程（协程）问题的定位非常困难

阅读全文 »

发表于 更新于 分类于 ， 本文字数： 7.2k 阅读时长 ≈ 7 分钟

本文续接锁实现分析：从glibc到futex（一）

上一篇对glibc和futex进行了源码分析，是我对具体实现的梳理，没有总结性的内容，可以略过不看直接看这一篇总结

本篇总结尝试深入一些，继续挖掘锁这个概念

分析内核在实现锁的过程中是如何解决无效唤醒问题的

为了解决无效唤醒问题，纯用户态的互斥锁性能不够好；纯内核态又在非竞争的条件时需要陷入内核，从而诞生了futex

阅读全文 »

发表于 更新于 分类于 ， 本文字数： 26k 阅读时长 ≈ 24 分钟

之前在理解条件变量时在futex上误入歧途，导致犯下死锁的错误，并且写下了错误的博文，见浅析条件变量

所以打算重新理解一下futex

虽然初衷是futex，但是由于futex最初是为了优化锁的性能而提出，因此深入理解futex实际上是对锁概念的深入了理解

因此本篇的大纲

源码分析从c++的mutex开始，然后是glibc的nptl库pthread_mutex，接着是linux内核的futex实现

阅读全文 »

发表于 更新于 分类于 本文字数： 20k 阅读时长 ≈ 18 分钟

我对内存屏障以及C++11引入的memory order一直处于一知半解的状态

知道有这么个东西，知道一部分原理，不知道什么场合去用它，一直以来我的多线程工具库里面只有锁，条件变量和原子变量三板斧，错过了很多更细粒度的优化机会。

在ChatGPT的帮助下，终于从头到尾理解了它的底层原理和应用场景

本文属于拾人牙慧的总结，将看到的一些资料整理出来，本文的大纲如下：

  • 缓存一致性

    从cpu缓存开始，引出多核cpu的缓存一致性(Cache Coherence)问题

    为了解决这个问题，发明了MESI协议，但是这个协议性能还不够好，因此引入了Store Buffer和Invalidate Queue来提高性能

  • 内存一致性

    Store Buffer，Invalidate Queue再加上编译器指令乱序和cpu指令乱序，导致了内存一致性(Memory Consistency)无法得到满足

    使用各种内存屏障来解决这些问题

  • C++的memory order

    为了简化和细化内存屏障，C++11引入了memory order

阅读全文 »

发表于 更新于 分类于 本文字数： 25k 阅读时长 ≈ 23 分钟

在C++中，有一些不太常见的小技巧，甚至有些能够被称之为黑魔法

判断类有没有某个方法，有这个方法才去调用

当你的代码需要同时服务某个库的新旧版本，希望调用新增接口，又不希望这个库的旧版本因为没有这个接口报错

对C++的基础库开发者来说，这是很常见的需求，因为你的库依赖的底层库，不一定可以强行指定版本，那么此时这个兼容性神器就可以出场了

这是一个简单的例子

阅读全文 »