Spin locks and software IRQs.

[n4ti1us]

Hi All,

I was looking at the linux kernel, and in the implementation of spinlocks, one can use different functions. One of them is spin_lock_bh(). What it does is it creates a spin lock and disables the software irqs.

In FreeBSD on the other hand, the implementation of spinlocks is done by mtx_lock_spin (which is actually a macro that calls mtx_lock_spin_flags()) but the problem is that is disables all the irq vector (at the bottom of the stack it executes an "cli"). Is there any way one can implement spinlocks that only disable the bottom half (sof irq)?

Alternatively, what would be the best way to manualy disable the soft irqs?

And all this makes me think... Why has nobody implemented a "_bh" version so far? Is this an architectural decision, or is it just me being blind?

[John Baldwin]

On Friday 16 May 2008 11:37:46 am n4ti1us wrote:

> Hi All,
>
> I was looking at the linux kernel, and in the implementation of spinlocks,
> one can use different functions. One of them is spin_lock_bh(). What it
> does is it creates a spin lock and disables the software irqs.
>
> In FreeBSD on the other hand, the implementation of spinlocks is done by
> mtx_lock_spin (which is actually a macro that calls mtx_lock_spin_flags())
> but the problem is that is disables all the irq vector (at the bottom of
> the stack it executes an "cli"). Is there any way one can implement
> spinlocks that only disable the bottom half (sof irq)?
>
> Alternatively, what would be the best way to manualy disable the soft irqs?
>
> And all this makes me think... Why has nobody implemented a "_bh" version
> so far? Is this an architectural decision, or is it just me being blind?

Generally one should use a regular mutex to protect data.  Spin locks in
FreeBSD are only used by scheduler internals or for a driver that has to
interact with an INTR_FAST handler (or filter in 7.x+).

--
John Baldwin
_______________________________________________
freebsd-drivers@... mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-drivers
To unsubscribe, send any mail to "freebsd-drivers-unsubscribe@..."