- Preemption Context Switches测量操作系统任务调度线程处理器上执行的次数，以及切换到较高-priority螺纹，数。
- Synchronization context switches度量的是因为显式调用线程同步API而发生线程切换的次数。如给多线程共享的变量加锁，多线程共同去改动。有些线程要堵塞在lock。直至占用锁的线程释放lock。这个度量反映的是线程间竞争的程度。
以下的实验来自VTune。旨在探究Preemption Context Switches的来源。
实验一：多线程无锁保护
speedup-example-no-mutex.cpp
#include#include #include #include #include #define N 4#define M 30000int 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
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#include #include #include #include #define N 4#define M 30000int 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
VTune现象： 接下来我们改变线程数。即N等于8：（我们期望Unknown处的Preemption添加类似线性，而clone处的添加幅度大。即与多线程无锁的情况类似）
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数目的效果基本一样。这与无锁是不同的。并且，有一个比較重要的区别：
在无锁的情况下，
A
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; }} 和 B
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; }} clone处Preemption的数目基本一致，但在加锁的情况下： C
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; }} 
和 D
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); }} 
clone处Preemption的数目不一样。前者要明显多于后者。可是假设我们将后者改为： E
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; }} 则VTune分析有： 
这就和 C 效果基本一样了。
而解释C、D、E三者之间的差异，也许也能够用我们的“时间理论”。运行三者：
C
D
E
尽管D的执行时比C和E稍小。但我们不能直接将无锁情况下的时间理论应用到加锁情况。
在说明原因之前。先看还有一个程序：
F
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; }} 
F
所以“执行时间不一样。clone处的Preemption数不一样”。在这里就不适用了。
看来无锁和加锁还是有个重要区别的。我们都知道在无锁情况下，全部子线程并行执行。VTune中有例如以下调度：
我们通过大量的观察发现，对于每一个线程。每相隔1s就会有一次Preemption Context Switches，所以无锁情况下。随着执行时间的添加。clone处的Preemption数会增多。
事实上“时间理论”也适用于加锁情况，那为什么会出现上面C、D、E的情况，以及D和F的情况？我们也从调度图入手：
C
D
F
事实上加锁和无锁的“时间理论”的差别在于：加锁情况中的C和D（基本串行化）。并非每个线程中每隔1s就有一个Preemption。而加锁情况中的F（拥有并行化），每个线程中每隔1s会有一个Preemption。
这样对于C和D。因为C的执行时较D长。当中包括的Preemption比D多；而F尽管执行时比D短，但每一个线程中的Preemption汇总就会和D一样多。
终于我们得出结论：
Preemption Context Switches的来源是——
对于拥有并行化的程序。执行时间越长，Preemption Context Switches越多；对于加锁导致串行化的程序，执行时间越长，Preemption Context Switches越多；对于加锁仍保留并行化的程序。执行时间越长，Preemption Context Switches越多。
版权声明：本文博客原创文章，博客，未经同意，不得转载。