动机和概述
这个小节又是一顿闲扯，想直接看方案的可以直接忽略。
在上海的时候，早上自然不必说，六点多的时候，全国各地哪哪路上都通畅，但是下班时就不一样了，由于我讨厌地铁站那种复杂无效的通行程序，为了能从闸北区快速到达嘉定区，我宁可先辗转到上海火车站，然后在那里坐全程高速的新嘉专线也不愿意去坐普通公交，这样保证一个小时内到达嘉定老城区，然后在小区家门口点一根烟…。当然，这得益于上海的快速路网络非常发达，超过10公里的路程基本都能保证80%以上甚至90%的快速路覆盖率，当然早晚高峰时，高架快速路也会通行缓慢，但是并不会停滞，即使再慢，也是缓慢前行的，这就是立体交通的好处。
深圳就完全不同了。深圳的快速路交通网络依然还处在发展之中，立体交通快速交通网络仍然不是很发达，很多时候，车辆不得不将大量的时间消耗在等待红绿灯这种事情上，特别是早晚高峰期的南山科技园片区，深南大道，科技路这个区域，简直让人有拆房子炸楼的冲动！早高峰我是能避开，晚高峰想避开则非常难。科技园深南大道北有北环，南有滨海，西有南海，东有沙河西，然而毛细血管还是不够，导致深南大道和科技路这些枝杈道路上的流量很难卸载到快速路网络上。
不过，看到这个新闻，心里还是有点小爽的：
深圳将新增“十横十三纵”总规模1041公里的高快速路网：http://news.sina.com.cn/c/2018-06-15/doc-ihcyszrz6832897.shtml
希望不要是纸上谈兵，这么大的一线城市，交通网络的优化应该是先行的。
现有的十字路口
为了讨论简便，我先不考虑行人，因为这可以用下沉式通道解决。不考虑行人的话，右转总是可行的，因此我也不会讨论右转的情况。在以上的约定下，先来看一下现如今的两种常见的十字路口放行规则：
可以看得出，无论哪种方式，都是同时只有两个车道可以并行放行。我在想，这是什么限制导致了这么低的并行度？
新的十字路口
前段时间考虑Linux TCP实现inet_hash函数时的spinlock问题，显然那是怕hash表被破坏而必须引入的串行机制，那么这里显然是为了防止车毁人亡而必须引入的lock机制，在面对那个TCP问题时，我使用per slot per cpu策略进一步细化了锁的粒度，稍微的空间换取了O(1)O(1)的inet_hash性能。
在十字路口问题上，仔细想想，其实是一道规则限制了想象力，即“靠右行驶”！稍微灵活地理解这个规则的限制，将会带来解锁后接近一倍的并行度提升！潮汐车道已经打破了人们对靠右行驶的思维定势，其实这里也是同样的思路。
在这里，我采用和TCP inet_hash完全同样的思路，即细化lock的粒度，同时“将左转待转区搬到对向车道！”来解锁，从而可以让对向两个直行，两个左转4个车道同时并行放行：
拆分了互斥的粒度后，其实也是用稍微的空间代价换取了时间上的高效。
其实，传统的左转待转区的设计本来也就是一个小小的优化，最初是没有这个左转待转区的，后来人们想到在一排车由于互斥确定还不能左转的时候，能不能让它们着手准备起来呢？然而，如果你把这个待转区放到对向那个中间的车道，就会发现，锁彻底解开来了。
当然，在细节上还存在很多的问题，但这些都是可以解决的。比如说下面的细节：
红色圆圈处是不是要拓宽一下呢？红色箭头表示车辆有一个斜穿的角度，这里是不是可以对其一下呢？比如下面的样子：
说白了，还是要增加带宽！
后记
想提高并行性，本质上就是一个解锁的过程，你要明白整个一个流程的每一个细节，哪个步骤在什么时间不能做，那么这段时间也不要让它闲着，试着做点准备工作或者随便其它什么。