MySQL引擎特性：InnoDB同步机制

random spin using ut_delay, spin max time depend on SPIN_WAIT_DELAY;

i++;

}

if (i == SPIN_ROUNDS) {

yield_cpu;

}

/*指导点2*/

if (__sync_lock_test_and_set(mutex->lock_word, 1) == 0) {

get mutex successfully;

return;

}

if (i < SPIN_ROUNDS) {

goto loop2

}

/*指导点4*/

get cell from sync array and call os_event_reset(mutex->event);

mutex->waiter =1;

/*指导点3*/

for (i = 0; i < 4; i++) {

if (__sync_lock_test_and_set(mutex->lock_word, 1) == 0) {

get mutex successfully;

free cell;

return;

}

sync array wait and os_event_wait(mutex->event);

goto loop1;

代码照样有点小复杂的。这里分析几点如下：

1. SPIN_ROUNDS控制了在放弃cpu时光片（yield_cpu）之前，一共进行若干次忙等，这个参数就是对外可设备的innodb_sync_spin_loops，而SPIN_WAIT_DELAY控制了每次忙等的时光，这个参数也就是对外可设备的innodb_spin_wait_delay。这两个参数一路决定了自旋的时光。Heikki Tuuri建议在单处理器的机械上调小spin的时光，在对称多处理器的机械上，可以恰当调大年夜。比较有意思的是innodb_spin_wait_delay的单位，这个是100MHZ的奔跑处理器处理1毫秒的时光，默认innodb_spin_wait_delay设备成6，表示最多在100MHZ的奔跑处理器上自旋6毫秒。因为如今cpu都是按照GHZ来计算的，所以按照默认设备自旋时光往往很短。此外，自旋不真是cpu傻傻的在那边100%的跑，在现代的cpu上，给自旋专门供给了一条指令，在笔者的测试情况下，这条指令是pause，查看Intel的文档，其对pause的解释是：不会产生用户态和内核态的切换，cpu在用户态自旋，是以不会产生高低文切换，同时这条指令不会消费太多的能耗。。。所以那些说spin lock太浪费电的不攻自破了。。。别的，编译器也不会把ut_delay给优化掉落，因为其琅绫擎估计修改了一个全局变量。

2. yield_cpu 操作在笔者的情况中，就是调用了pthread_yield函数，这个函数把放弃当前cpu的时光片，然后把当前哨程放到cpu可履行队列的末尾。

3. 在指导点1后面的轮回，没有采取原子操作攫取数据，是因为，Heikki Tuuri认为因为原子操作在内存和cpu cache之间会产生过的数据交换，如不雅只是读本地的cache，可以削减总线的┞幅用。即使本地读到脏的数据，也没紧要，因为在彪炳轮回的指导点2，依然会再一次应用原子操作进行校验。

5/9 首页上一页 3 4 5 6 7 8 下一页尾页

　　推荐阅读

　　海尔王养浩：让IT成为业务和创新的赋能者

数字化转型已成为趋势，然而既然是转型则必定会带来阵痛，新技巧在带来新的颠覆的同时，也给IT运维治理带来新的挑衅，包含稳定性、扩大性、灵活性、成本、投资回报率等等。对于IT治理者而言，若何经由过程大年夜数据>>>详细阅读

本文标题：MySQL引擎特性：InnoDB同步机制

地址：http://www.17bianji.com/lsqh/39799.html

1/2 1