context 语句
Context(上下文),可以理解为一种协调 Go 协程的东西 —— 我们可以创建、运行一个 Go 协程,缺乏一种传递取消信号和截止时间的机制,便引入了 Context。
TAG_COLLECTION //
共有 32 篇笔记使用了这个 Tag。
Context(上下文),可以理解为一种协调 Go 协程的东西 —— 我们可以创建、运行一个 Go 协程,缺乏一种传递取消信号和截止时间的机制,便引入了 Context。
select用于监听多个channel
本质上是用于等待一组任务完成的计数同步原语
工作池,一种并发设计,其中有两个主要概念 - 工人:干工作的工人 - 工作:分配的任务
简单来说,就是不可被中断的操作,要么完全执行,要么不执行,不存在中间状态
首先,CPU 访问速度和主内存的运行速度一定存在差异,且 CPU 的速度快于内存的速度。假设没有缓存机制,那么代码的执行顺序——从内存中读取指令和必要数据等,然后运算,接着等待内存传输数据,这边等待的时候,就严重降低了运算速度——我们的运算上限被内存的运算速度给限制住了!
首先对于单个原子操作语句来说, 它在外部看来一定是原子操作(废话), 也就是不存在“中间态”.
是共享状态进行访问或修改的代码片段,要求在任意时刻,线程执行到这个片段的时候,只有唯一一种执行流可以正确执行以保证数据的不变性
一个重点在关注数据上的建模. 原先最朴素的做法是把生产和消费是串行并且集成在同一个模块内 —— 即生产完成后直接进行消费, 那么此时生产和消费在执行时序上是紧密关联的.
或许可以大致分为三个部分 ——
虽然一直在说“锁可以保护临界区资源”,但是忽然发现笔记中没有任何一篇专门说锁的??!
与锁不同,它感觉更偏向是线程之间通讯的一种方式 —— A 因需要等待某条件为真后才能继续运行于是进入 waiting 状态;此时 B 执行到设置这个条件为真后, A 继续运行
简述一下之间的区别与联系 (假设使用时间片轮转的抢占式调度方式,其实还有优先级调度、多级反馈队列(MLFQ)、完全公平调度(CFS)等调度方式
死锁活锁和饥饿是破坏系统活跃性的主要三种问题.
打算稍微说说 Job System 中的 threadlocal 声明的变量的用途
一般来说,线程可以被
主要分为 ——
把异步理解成为一种目的 —— 不需要通过阻塞当前线程来等待某一操作的完成,而是继续执行接下来的逻辑,直到那个操作完成之后回调通知当前线程。
std::atomic, 用于定义原子变量, 允许多个线程按照 C++ 内存模型进行读写等操作. 一般用于线程之间共享状态等.
条件变量, 用于阻塞等待的同步元语.
这是一个编外篇, 简单说明清楚一下使用一个 localthread 来记录当前线程的设计.
Future, 表示这个结果我会在未来进行消费. 那么它具体怎么生产出来玩无所谓. 我持有 std::future 只是一个消费者而已.
- G:Goroutine,Go协程 - P:Processor,逻辑处理器 - M:Machine,操作系统线程
通道(Channel)用于协程之间的数据通信,通道操作自身可安全地并发使用,并为对应的发送和接收提供同步关系,但不会自动消除其他共享状态的数据竞态。通道本质上是一个队列(FIFO)
把一些可以并行执行的 CPU 工作交给 Worker 去做,比如资产加载、可见性计算、后台统计等。
存储Job数据的地方(看名字也非常显然), 看 API 非常好理解其用法用途, 不过还是稍微说下其中的一些设计
简单说下这个方法的设计, 其实非常的简单, 就是上游业务调用的时候, 可以把一个大的 Range 拆分成若干小的 Chunk 然后进行并行执行.
在 Future 的时候说到, 它表示一个消费者 —— 我在未来可能要消费某个数据.
简述 C++ 中的并发,聚焦在std::thread (不得不说,还得是你 golang
由这个关键字声明的变量, 在每一个线程内都有一个自己独立的实例.
假设一个线程调用了 Wait() 方法, 那么首先它确乎是会阻止代码继续往下运行, 而是等待任务执行完毕.
当前的实现是, 优先执行自己队列中的任务, 如果空闲的话, 先尝试从全局的 InjectionQueue 中尝试接单, 如果还是空闲, 则尝试从其他 Worker 的队列中领任务. 如果还是空, 则进入休眠,交出资源,等待唤醒.