MPI/Pthreads/openmp

—–缓存一致性 是行级的
———伪共享 ：线程对内存访问的行为好像在共享一个变量，实际上：不同线程访问（更新）相同缓存行的不同变量（非共享变量），缓存控制器会使整个缓存行无效，强制访问线程从内存获取变量的值。

我们一定要通过缓存行填充去解决掉潜在的伪共享问题吗？
其实并不一定。

首先就是多次强调的，伪共享是很隐蔽的，我们暂时无法从系统层面上通过工具来探测伪共享事件。其次，不同类型的计算机具有不同的微架构（如 32 位系统和 64 位系统的 java 对象所占自己数就不一样），如果设计到跨平台的设计，那就更难以把握了，一个确切的填充方案只适用于一个特定的操作系统。还有，缓存的资源是有限的，如果填充会浪费珍贵的 cache 资源，并不适合大范围应用。最后，目前主流的 Intel 微架构 CPU 的 L1 缓存，已能够达到 80% 以上的命中率。

综上所述，并不是每个系统都适合花大量精力去解决潜在的伪共享问题。
——-openmp
- 任务并行化 显示线程同步 缓存-共享内存 串行代码-共享内存程序
- gcc -g -Wall -fopenmp -o omp_hello omp_hello.c
- 对for 循环 1.每个线程分配子任务，2. 显示并行化
#pragma omp parallel num_threads(thread_count)+ critical
#pragma omp parallel num_threads(thread_count)\
reduction(+:global_result) //规约变量来避免串行执行 减法、浮点会有点问题，因为不满足交换律和结合律；规约变量是共享变量
3. #pragma omp parallel_for num_threads(thread_count)\
reduction(+:global_result)
- 作用域： parallel指令 变量缺省作用域 共享 ；parallel for 私有
- 两个临界区：atomic done_sending++ 和”复合”临界区
- 对临界区访问：三种机制
#pragma omp atomic
#pragma omp critical
锁 使用互斥的是某个数据结构，而不是代码块
- atomic 性能最快，但如果有多个不同内存的变量被atomic 指令保护，可用critical（隐式/显示）
后两个性能差不多
- 锁：简单锁 嵌套锁
简单锁 omp_lock：释放前 同一个进程获得一次
嵌套锁： 多
omp_init_lock set unset destroy
- 循环调度 （openMP中将循环分配给线程，称为调度）
1.schedule ([,])
type: static （缺省情况下）迭代在循环 执行前 分配给线程，轮转方式 如0 3 6 9；1 4 7 10；2 5 8 11（迭代号）；
dynamic / guided 执行时，一个线程完成，从运行时系统请求另一块；后者新块大小会变小
auto 调度方式由 编译器和运行时系统决定
runtime 调度在运行时决定
–调度选择
1.每次迭代 相同计算量 默认
2.计算量线性增加， 较小chunck-size 的static
3.开销事先不确定，尝试不同的策略
schdule(runtime),通过不同的环境变量OMP_SCHEDULE 不同的值比较不同的调度策略

—pthreads
- 临界区
一次一个线程
-临界区 限制访问：
1 忙等待 持续使用CPU,不理想
2 互斥量（互斥锁简称）pthread_mutex_t_init lock(&mutex) unlock destroy
线程执行顺序 由 系统随机 选择
—>互斥量数组
3 信号量
sem_init wait post destroy（初始化为1 开锁，临界区前调用sem_wait,如信号量0，线程阻塞，非0，减1，进入临界区，出来时调用sem_post 加1，使得wait中阻塞的其他线程继续运行）