mutex lock add retries

[beef9999]

经过验证：给mutex增加重试后，对多线程程序的整体性能有帮助。

使用rocksdb的db_bench做测试，关闭compaction，数据全在block cache(内存)，启动8个线程做读IO测试。通过观察OPS，比较跨线程锁的开销。

TODO:

1. 选取合理的retry number。在单线程和多线程程序做一些取舍。会在单线程多协程的场景稍微增加一些开销；而在多线程的场景下，相当于是用富余的CPU计算换取更高的cacheline命中率，降低锁延时。
2. 将原先代码里的一些spinlock换成新的mutex。如thread_pool里面的，当时也是为了多线程优化改的spinlock

[beef9999]

补充测试1：

Photon版本

线程数（vcpu）	并发数（thread）	Mutex重试次数	OPS (Million/s )
1	1	-	0.47
4	4	-	1.70

原版

核心数（core）	并发数（thread）	Mutex重试次数	OPS (Million/s )
1	1	-	0.49
4	4	-	1.96

结论：并发不高的情况下，photon mutex对比pthread mutex还有优化空间

补充测试2

Photon版本

线程数（vcpu）	并发数（thread）	Mutex重试次数	OPS (Million/s )
1	32	50	0.81
1	32	100	0.80
1	32	200	0.80
1	32	500	0.79

结论：单线程下，mutex重试次数对性能影响很小。

补充测试3

Photon版本

线程数（vcpu）	并发数（thread）	Mutex重试次数	OPS (Million/s )
4	32	50	2.12
4	32	100	2.64
4	32	200	2.61

原版

核心数（core）	并发数（thread）	Mutex重试次数	OPS (Million/s )
4	32	-	2.36

结论：高并发条件下，协程开始优于线程；重试次数=100是个较好的选择。

[lihuiba]

looks great!