1.Ray 源码解析（一）：任务的共享共享状态转移和组织形式
2.最佳实践 | CentOS 和 Ubuntu 下安装配置 GreenPlum 数据库集群 - 源码 & 安装包
3.mmap的系统调用
4.GPU编程9：共享内存3→线程同步和数据布局
5.Nginx源码分析 - 主流程篇 - 全局变量cycle初始化
Ray 源码解析（一）：任务的状态转移和组织形式
Ray源码解析系列的第一篇着重于任务的状态管理和组织形式。Ray的内存内存核心设计在于其细粒度、高吞吐的源码源码任务调度，依赖于共享内存的共享共享Plasma存储输入和输出，以及Redis的内存内存GCS来管理所有状态，实现去中心化的源码源码约炮 app 源码调度。任务分为无状态的共享共享Task和有状态的Actor Method，后者包括Actor的内存内存构造函数和成员函数。
Ray支持显式指定任务的源码源码资源约束，通过ResourcesSet量化节点资源，共享共享用于分配和回收。内存内存在调度时，源码源码需找到满足任务资源要求的共享共享节点。由于Task输入在分布式存储中，内存内存调度后需要传输依赖。源码源码对于Actor Method，其与Actor绑定，会直接调度到对应的节点。
状态变化如任务状态转移、资源依赖等信息，网贷源码asp都存储在GCS中。任务状态更改需更新GCS，失联或宕机时，根据GCS中的状态信息重试任务。通过GCS事件订阅驱动任务状态变化。
文章主要讲述了任务状态的组织方式，如任务队列（TaskQueue）和调度队列（SchedulingQueue）的运作，以及状态转移图和状态枚举类的定义。例如，TaskQueue负责任务的增删查改，其中ReadyQueue通过资源映射优化调度决策。此外，文中还解释了一些关键概念，如Task Required Resources、Task argument、Object、Object Store、Node/Machine等。
后续文章将深入探讨调度策略和资源管理。seo页群源码让我们期待下篇的精彩内容。
最佳实践 | CentOS 和 Ubuntu 下安装配置 GreenPlum 数据库集群 - 源码 & 安装包
本文首先发布于年1月日，旨在为CentOS/RedHat和Ubuntu/Debian平台的用户提供GreenPlum数据库集群的安装和配置指南，包括通过安装包和源码安装的详细步骤。 1. 安装步骤规划阶段：在两台机器h和h上分别设置1个主master，2个主segment和2个镜像segment，h上配置1个备master。
安装前的准备：分别在两台机器上安装必要的依赖，具体操作根据不同操作系统进行。
安装方式：可以选择安装包或源码方式。
1.4.1. 源码安装从源码克隆，若遇到python包缺失，可参考HAWQ项目进行处理。
编译完成后，进行系统参数设置，如内核内存参数、共享内存和文件读写配置。
1.6. 示例：创建demo集群 安装完成后，可以创建一个包含3个segment的哪里有语言源码demo集群，但这一步骤可按需跳过。 1.. 节点部署优化：如果所有节点需部署在一台主机，只需调整配置文件和目录结构。 2. GreenPlum常用操作启动、停止、重启集群，以及维护模式操作和数据库访问。
GUC参数配置，包括全局和master-only配置，设置后可能需要重启或reload配置。
最后，记得在使用任何GreenPlum命令前，先执行相关初始化步骤。如有更多技术分享，可关注微信公众号数据库内核。mmap的系统调用
1. 创建内存映射
mmap：进程创建匿名的内存映射，把内存的物理页映射到进程的虚拟地址空间。进程把文件映射到进程的虚拟地址空间，可以像访问内存一样访问文件，快速问医源码不需要调用系统调用read()/write()访问文件，从而避免用户模式和内核模式之间的切换，提高读写文件速度。两个进程针对同一个文件创建共享的内存映射，实现共享内存。
mumap：该调用在进程地址空间中解除一个映射关系，addr是调用mmap()时返回的地址，len是映射区的大小。当映射关系解除后，对原来映射地址的访问将导致段错误发生。
3. 设置虚拟内存区域的访问权限
mprotect：把自start开始的、长度为len的内存区的保护属性修改为prot指定的值。 prot可以取以下几个值，并且可以用“|”将几个属性合起来使用： 1）PROT_READ：表示内存段内的内容可写； 2）PROT_WRITE：表示内存段内的内容可读； 3）PROT_EXEC：表示内存段中的内容可执行； 4）PROT_NONE：表示内存段中的内容根本没法访问。 需要指出的是，指定的内存区间必须包含整个内存页（4K）。区间开始的地址start必须是一个内存页的起始地址，并且区间长度len必须是页大小的整数倍。
0. 查找mmap在内核中的系统调用函数 我现在用的内核版是4..，首先在应用层参考上面解析编写一个mmap使用代码，然后编译成程序，在使用strace工具跟踪其函数调用，可以发现mmap也是调用底层的mmap系统调用，然后我们寻找一下底层的带6个参数的mmap系统调用有哪些：
1.mmap的系统调用 x的位于arch/x/kernel/sys_x_.c文件，如下所示：
arm的位于arch/arm/kernel/sys.c文件，如下所示：
然后都是进入ksys_mmap_pgoff：
然后进入vm_mmap_pgoff：
我们讲解最重要的do_mmap_pgoff函数：
然后进入do_mmap：
do_mmap_pgoff这个函数主要做了两件事，get_unmapped_area获取未映射地址，mmap_region映射。 先看下get_unmapped_area ，他是先找到mm_struct的get_unmapped_area成员，再去执行他：
再看mmap_region的实现：
现在，我们看看匿名映射的函数shmem_zero_setup到底做了什么，其实匿名页实际也映射了文件，只是映射到了/dev/zero上，这样有个好处是，不需要对所有页面进行提前置0，只有当访问到某具体页面的时候才会申请一个0页。
其实说白了，mmap就是在进程mm中创建或者扩展一个vma映射到某个文件，而共享、私有、文件、匿名这些mmap所具有的属性是在哪里体现的呢？上面的源码在不断的设置一些标记位，这些标记位就决定了进程在访问这些内存时内核的行为，mmap仅负责创建一个映射而已。
GPU编程9：共享内存3→线程同步和数据布局
并行线程间的同步是所有并行计算语言的重要机制，确保数据一致性与程序顺序执行。共享内存可以同时被线程块中的多个线程访问，当不同步的多个线程修改同一个共享内存地址时，将导致线程内的冲突。CUDA提供障碍(barrier)和内存栅栏(memory fences)来实现块内同步。
在弱排序内存模型下，GPU线程在不同内存写入数据的顺序不一定和这些数据在源码中的顺序相同，且一个线程的写入顺序对其他线程可见时，可能与写操作被执行的实际顺序不一致。为了显式地强制程序确切顺序执行，必须在代码中插入内存栅栏和障碍。
同步方法包括显式障碍和内存栅栏。显式障碍只能在同一线程块的线程间执行，通过调用void __syncthreads()函数来指定一个barrier点。__syncthreads作为barrier点要求块中的线程必须等待直到所有线程都到达该点。内存栅栏功能可确保栅栏前的任何内存写操作，对栅栏后的其他线程都是可见的，包括块、网格或系统级的内存栅栏。
Volatile修饰符用于防止编译器优化，避免数据在寄存器或本地内存中被缓存。GPU全局内存常驻在设备内存（DRAM)，访问粒度可以是个字节或个字节，共享内存的访问粒度为4字节或8字节存储体宽。
数据布局通过选择共享内存的形状和访问方式来优化全局内存加载。方形共享内存块可以通过相邻线程访问邻近元素来优化，最佳实现方式是按行主序写、按行主序读。对于行列不等长的矩阵转置，可以使用共享内存进行并行归约或展开并行归约，以减少全局内存的访问。
通过全局内存进行矩阵转置时，读取行、存储列或读取列、存储行都会有一次读写的交叉访问。使用共享内存作为中转可以提高效率，因为共享内存相比全局内存有更好的带宽。共享内存中的交叉访问效率也高于全局内存。
性能上下限在不同硬件下表现可能不同，具体原因尚不明确。在实际编码中需要注意这个问题。
Nginx源码分析 - 主流程篇 - 全局变量cycle初始化
Nginx的全局初始化过程围绕全局变量“cycle”展开，位于/src/core/cycle.c文件，其数据结构为“ngx_cycle_t”。了解Nginx源码前应掌握cycle全局变量初始化流程。 cycle初始化分为以下步骤： 创建内存池 用于后续分配的所有内存。 拷贝配置文件路径前缀 如“/usr/local/nginx”，存储在cycle->conf_prefix中。 复制Nginx路径前缀 存储于cycle->prefix。 复制配置文件信息 包含文件路径，如“/nginx/conf/nginx.conf”。 复制配置参数信息 初始化路径信息 初始化打开的文件句柄 初始化shared_memory链表 新旧链表比较，保留相同内存，释放不同。 遍历并打开文件列表（如日志、配置文件） 创建并初始化共享内存 比较新旧共享内存，保留或创建。 处理listening数组并开始监听 处理socket监听。 关闭或删除old_cycle资源 关键点在于内存池的创建、配置文件解析、文件句柄与共享内存的初始化、socket监听与资源关闭，整个流程确保Nginx核心组件的初始化完成。