首页 > 代码库 > Preemption Context Switches 和 Synchronization Context Switches
Preemption Context Switches 和 Synchronization Context Switches
- Preemption Context Switches度量的是操作系统任务调度器将处理器中的一个正在运行的线程切换为另一个更高优先级的线程的次数，即发生抢占的次数。
- Synchronization context switches度量的是由于显式调用线程同步API而发生线程切换的次数，如给多线程共享的变量加锁，多线程共同去修改，有些线程要阻塞在lock，直至占用锁的线程释放lock，这个度量反映的是线程间竞争的程度。
下面的实验来自VTune，旨在探究Preemption Context Switches的来源。
实验一：多线程无锁保护
speedup-example-no-mutex.cpp
#include <pthread.h>
#include <stdio.h>
#include <stdlib.h>
#include <errno.h>
#include <assert.h>
#define N 4
#define M 30000
int nwait = 0;
volatile long long sum;
long loops = 6e3;
void set_affinity(int core_id) {
cpu_set_t cpuset;
CPU_ZERO(&cpuset);
CPU_SET(core_id, &cpuset);
assert(pthread_setaffinity_np(pthread_self(), sizeof(cpu_set_t), &cpuset) == 0);
}
void* thread_func(void *arg) {
set_affinity((int)(long)arg);
for (int j = 0; j < M; j++) {
nwait++;
for (long i = 0; i < loops; i++)
sum += i;
for (long i = 0; i < loops; i++)
sum += i*i*i*i*i*i;
}
}
int main(int argc, char *argv[]) {
set_affinity(23);
pthread_t th[N];
int ret;
for(unsigned i=0; i<N; ++i) {
ret = pthread_create(&th[i], NULL, thread_func, (void*)i);
assert(!ret && "pthread_create() failed!");
}
for(unsigned i=0; i<N; ++i)
pthread_join(th[i], NULL);
exit(0);
}
VTune现象：
Preemption Context Switches由两部分组成：clone和Unknown stack frame(s)。
- 后者的Preemption稳定在5：在这个程序中，共有5个线程在运行，VTune显示每个线程各占1，所以后者的Preemption才稳定在5上。为了验证，我们让N等于8，结果是每个线程各占1，Unknown stack frame(s)处的Preemption稳定在9。
- clone处的Preemption不是一个确定的数，有可能是6、7、8等。
通过上图可以发现clone处的Preemption都分布在四个子线程中。下面再来一组：
通过比较上面三幅图，我们发现四个子线程所占的Preemption数并不总是均等。为了验证，我们让N等于8，结果如下：
果然clone处的Preemption并不是由子线程均分。不过随着线程数增加，clone处Preemption的增加幅度要大于Unknown stack frame(s)处。
通过上面的现象，我们尝试做出结论：
由于没有锁，所以线程间是独立的，我们单独分析一个线程中Preemption Context Switches的来源即可（其实这种假设是有问题的，因为我们上面提到随着线程数增加，Preemption并没有线性增加，如果各线程间相互独立，理应是线性增加的，不过我们先从简单情况入手）。我们尝试逐步减少子线程执行任务的办法：
void* thread_func(void *arg) { set_affinity((int)(long)arg); for (int j = 0; j < M; j++) { for (long i = 0; i < loops; i++) sum += i*i*i*i*i*i; } }void* thread_func(void *arg) { set_affinity((int)(long)arg); for (int j = 0; j < M; j++) { for (long i = 0; i < loops; i++) sum += i; } }void* thread_func(void *arg) { set_affinity((int)(long)arg); for (int j = 0; j < M; j++) { nwait++; } }
无clone处的Preemption Context Switches
通过上面我们就断定当子线程计算任务变轻时，clone处的Preemption会变少，这是武断的。因为如下：
void* thread_func(void *arg) { set_affinity((int)(long)arg); for (int j = 0; j < M; j++) { for (long i = 0; i < loops; i++) sum += i; for (long i = 0; i < loops; i++) sum += i; } }
这个子线程的计算任务要比上面三个中的第一个要轻，但它的Preemption数却要多，所以我初步猜想是第二层for循环的个数决定了clone处的Preemption数，于是做以下验证：
void* thread_func(void *arg) { set_affinity((int)(long)arg); for (int j = 0; j < M; j++) { for (long i = 0; i < loops; i++) sum += i; for (long i = 0; i < loops; i++) sum += i; for (long i = 0; i < loops; i++) sum += i; } }void* thread_func(void *arg) { set_affinity((int)(long)arg); for (int j = 0; j < M; j++) { for (long i = 0; i < loops; i++) sum += i; for (long i = 0; i < loops; i++) sum += i; for (long i = 0; i < loops; i++) sum += i; for (long i = 0; i < loops; i++) sum += i; } }
确实是随着for循环的增多，clone处的Preemption在增多，但以此下结论还是不妥，合理的验证还应有以下工作：
void* thread_func(void *arg) { set_affinity((int)(long)arg); for (int j = 0; j < M; j++) { for (long i = 0; i < loops; i++) { sum += i; sum += i; sum += i; sum += i; } } }
奇怪明明这个子线程的工作量和上面验证中的第二个一样，而且它只有一个for，但clone处的Preemption却更多，于是继续做验证：
void* thread_func(void *arg) { set_affinity((int)(long)arg); for (int j = 0; j < M; j++) { for (long i = 0; i < loops; i++) { sum += i; sum += i; sum += i; sum += i; sum += i; sum += i; sum += i; } } }
最终结论：
也就是说随着第二层for的个数增加，clone处Preemption在增加；如果第二层只有一个for，那么随着这个for中的子句（上面的实验只能说明本例中出现的子句sum+=i有这种情况）的增多，clone处的Preemption在增加。
分析：
如果说这是结论，那为什么？子线程在执行时，频繁被更高优先级的进程给抢占，可能是时间，运行时间，当子线程运行时间长时，系统中更高优先级的进程抢占它的情况更多。果然，我们重新执行上述那些验证程序，发现——clone处Preemption多的程序，它的运行时间越长。
void* thread_func(void *arg) { set_affinity((int)(long)arg); for (int j = 0; j < M; j++) { for (long i = 0; i < loops; i++) sum += i; for (long i = 0; i < loops; i++) sum += i; for (long i = 0; i < loops; i++) sum += i; for (long i = 0; i < loops; i++) sum += i; } }void* thread_func(void *arg) { set_affinity((int)(long)arg); for (int j = 0; j < M; j++) { for (long i = 0; i < loops; i++) { sum += i; sum += i; sum += i; sum += i; } } }
至于为什么，或许是因为编译器的优化。这里我们要专注于我们一开始的问题：Preemption Context Switches从何而来。从执行时间而来。当然这只是针对多线程间无锁情况，下面给它加上锁，看看是否有哪个因素也会影响到Preemption Context Switches。
实验二：多线程加锁
speedup-example-mutex-only.cpp
#include <pthread.h>
#include <stdio.h>
#include <stdlib.h>
#include <errno.h>
#include <assert.h>
#define N 4
#define M 30000
int nwait = 0;
volatile long long sum;
long loops = 6e3;
pthread_mutex_t mutex;
void set_affinity(int core_id) {
cpu_set_t cpuset;
CPU_ZERO(&cpuset);
CPU_SET(core_id, &cpuset);
assert(pthread_setaffinity_np(pthread_self(), sizeof(cpu_set_t), &cpuset) == 0);
}
void* thread_func(void *arg) {
set_affinity((int)(long)arg);
for (int j = 0; j < M; j++) {
phtread_mutex_lock(&mutex);
nwait++;
for (long i = 0; i < loops; i++)
sum += i;
phtread_mutex_unlock(&mutex);
for (long i = 0; i < loops; i++)
sum += i*i*i*i*i*i;
}
}
int main(int argc, char *argv[]) {
set_affinity(23);
pthread_t th[N];
int ret;
for(unsigned i=0; i<N; ++i) {
ret = pthread_create(&th[i], NULL, thread_func, (void*)i);
assert(!ret && "pthread_create() failed!");
}
for(unsigned i=0; i<N; ++i)
pthread_join(th[i], NULL);
exit(0);
}
VTune现象：
Unkown stack frame(s)的对Preemption Context Switches的贡献率任然不如clone。且在同等数目线程下，加锁情况下的clone要比不加锁的制造更多的Preemption Context Switches。如果用我们上面的“时间理论”来解释——加锁的运行时间明显比不加锁要多，也能解释，不过这并不充分，让我们执行以下验证：
void* thread_func(void *arg) { set_affinity((int)(long)arg); for (int j = 0; j < M; j++) { phtread_mutex_lock(&mutex); nwait++; for (long i = 0; i < loops; i++) sum += i; phtread_mutex_unlock(&mutex); } }void* thread_func(void *arg) { set_affinity((int)(long)arg); for (int j = 0; j < M; j++) { phtread_mutex_lock(&mutex); nwait++; phtread_mutex_unlock(&mutex); for (long i = 0; i < loops; i++) sum += i*i*i*i*i*i; } }void* thread_func(void *arg) { set_affinity((int)(long)arg); for (int j = 0; j < M; j++) { phtread_mutex_lock(&mutex); nwait++; phtread_mutex_unlock(&mutex); } }void* thread_func(void *arg) { set_affinity((int)(long)arg); for (int j = 0; j < M; j++) { phtread_mutex_lock(&mutex); nwait++; for (long i = 0; i < loops; i++) sum += i; for (long i = 0; i < loops; i++) sum += i; phtread_mutex_unlock(&mutex); } }void* thread_func(void *arg) { set_affinity((int)(long)arg); for (int j = 0; j < M; j++) { phtread_mutex_lock(&mutex); nwait++; for (long i = 0; i < loops; i++) sum += i; for (long i = 0; i < loops; i++) sum += i; for (long i = 0; i < loops; i++) sum += i; for (long i = 0; i < loops; i++) sum += i; phtread_mutex_unlock(&mutex); } }void* thread_func(void *arg) { set_affinity((int)(long)arg); for (int j = 0; j < M; j++) { phtread_mutex_lock(&mutex); nwait++; for (long i = 0; i < loops; i++) { sum += i; sum += i; sum += i; sum += i; } phtread_mutex_unlock(&mutex); } }
我们发现，基本上加锁情况与无锁情况一致，不过我们还需做以下验证：
void* thread_func(void *arg) { set_affinity((int)(long)arg); for (int j = 0; j < M; j++) { phtread_mutex_lock(&mutex); nwait++; phtread_mutex_unlock(&mutex); for (long i = 0; i < loops; i++) sum += i*i*i*i*i*i; for (long i = 0; i < loops; i++) sum += i*i*i*i*i*i; } }void* thread_func(void *arg) { set_affinity((int)(long)arg); for (int j = 0; j < M; j++) { phtread_mutex_lock(&mutex); nwait++; phtread_mutex_unlock(&mutex); for (long i = 0; i < loops; i++) sum += i*i*i*i*i*i; for (long i = 0; i < loops; i++) sum += i*i*i*i*i*i; for (long i = 0; i < loops; i++) sum += i*i*i*i*i*i; for (long i = 0; i < loops; i++) sum += i*i*i*i*i*i; } }void* thread_func(void *arg) { set_affinity((int)(long)arg); for (int j = 0; j < M; j++) { phtread_mutex_lock(&mutex); nwait++; phtread_mutex_unlock(&mutex); for (long i = 0; i < loops; i++) { sum += i*i*i*i*i*i; sum += i*i*i*i*i*i; sum += i*i*i*i*i*i; sum += i*i*i*i*i*i; } } }
果然，在一定误差可容忍下，for循环是不区别加锁for和不加锁for，它们取得的效果基本一样——随着第二层for的数目增加，clone处的Preemption在增加；不过这里，单个for中增加子句的效果和增加for数目的效果基本一样，这与无锁是不同的；而且，
声明：以上内容来自用户投稿及互联网公开渠道收集整理发布，本网站不拥有所有权，未作人工编辑处理，也不承担相关法律责任，若内容有误或涉及侵权可进行投诉： 投诉/举报 工作人员会在5个工作日内联系你，一经查实，本站将立刻删除涉嫌侵权内容。