多核下锁的使用

Godbach

不知道你这个到底需要多快.在一般处理器上spinlock对于操作短队列足够了,你可以改进hash使得分成更多列
我曾经弄过一个办法,就是在每个单独的列上使用一个lock,各个列同样可以并行访问

smalloc 兄，如果我想操作某列上的某个元素，那么调用的是 spin_lock_bh 的话，单个列上使用一个锁或者整个hash 使用一个锁，应该是没有区别的吧。

smalloc

回复 21# Godbach


    spin_lock从来只对多处理器.如果你单处理器且不考虑通用性的话.都一样.

Godbach

我需要考虑的就是多处理器，如果带了_bh 的话，禁用了软中断，你锁住整个hash 或者 单个列，处理期间，都不能再接收数据包了吧

smalloc

回复 23# Godbach


    这个不会
硬中断可能会胶合在某个处理器
但是同一个类型的软中断却可能在不同的处理器上并行,至于平衡什么的.没研究过.记得思一克的一个帖子讨论过.
禁止BH并不能禁止硬件中断.而且只能禁止本处理器软中断.

Godbach

但是同一个类型的软中断却可能在不同的处理器上并行,至于平衡什么的.没研究过.记得思一克的一个帖子讨论过.

嗯，应该是的。不同处理器上是可以并行的。

禁止BH并不能禁止硬件中断.而且只能禁止本处理器软中断.否则软中断也不能在不同处理器上并行了.

嗯，_bh 的时候，也就是禁用本地处理器的软中断。其他处理器的同类型软中断照常可以产生。

因此，对于 spin_lock_bh, 是否可以这样简单总结:
(1) 用 _bh 禁用本地处理器的软中断；
(2) 用 spin_lock 来防止多处理器对临界资源的访问。

platinum

我觉得 spin_lock_bh 应该比 spin_lock 锁的更死才对
并不是说 _bh 就不能防止多处理器对临界资源的访问
所以上面总结的第一点可能有问题
除此之外，spin_lock_bh 还可以保护很多上下文，这是 spin_lock 做不到的

Godbach

我觉得 spin_lock_bh 应该比 spin_lock 锁的更死才对
并不是说 _bh 就不能防止多处理器对临界资源的访问

这个地方，白金兄能否深入介绍一下

raintung

当进程访问和软中断访问共享资源的时候，需要用spin_lock_bh 避免死锁
在进程运行过程中，会被硬中断打断，而执行软中断，如果使用spin_lock 会导致死锁，
而使用spin_lock_bh 就不会，因为已经把软中断关闭了。

不知道我理解是否正确？
感觉更多的是用户层的使用，软中断执行是串行的在同cpu下，即使被硬中断切换出去，还是会继续执行原来的中断。

个人有个问题 是在内核态 和软中断的执行过程中 除了硬中断，还能被其他的事件打断么？ 因该不受进程的时间片的调度吧？

platinum

当进程访问和软中断访问共享资源的时候，需要用spin_lock_bh 避免死锁
在进程运行过程中，会被硬中断打断， ...
raintung 发表于 2010-11-02 13:49

对，正是如此

smalloc

当进程访问和软中断访问共享资源的时候，需要用spin_lock_bh 避免死锁
在进程运行过程中，会被硬中断打断，而执行软中断，如果使用spin_lock 会导致死锁，
raintung 发表于 2010-11-02 13:49

       虽然事实如此.但解释实在过于牵强.
BH 确实只使用在进程上下文.
但是首先搞清楚并不是因为要避免死锁而使用spin_lock_bh ,而是保证同处理器中进程和软中断的交叉访问.在保证这点的情况下,你根本看不到死锁.
自旋锁和禁止BH本身是2个独立的功能,但是在合用的时候 BH是第一性的.也就是自旋这个时候是配合BH.
因为任何多处理器都是首先建立在单处理器基础上的.
所以2个功能在一起的时候总是先禁BH然后在获取自旋锁.这个是有讲究的.而不是颠倒过来.否则同样会死锁