FreeBSD spinlock - compatibility layer
Orit Moskovich
oritm at mellanox.com
Tue May 21 04:37:08 UTC 2013
That's not the case when using taskqueues for deferring execution of an interrupt handler.
Tasks can be delayed using the global taskqueue taskqueue_swi, which executes its tasks in the context of an interrupt.
In this case sleep is forbidden, and using spin mutex is not (although might be not recommended).
-----Original Message-----
From: John Baldwin [mailto:jhb at freebsd.org]
Sent: Monday, May 20, 2013 11:42 PM
To: freebsd-arch at freebsd.org
Cc: Orit Moskovich
Subject: Re: FreeBSD spinlock - compatibility layer
On Tuesday, May 14, 2013 6:04:21 am Orit Moskovich wrote:
> Hi,
>
> I read about the FreeBSD mutex implementation for spinlock in the
compatibility layer.
> I might be wrong, but I noticed a code section that might be problematic:
>
> Taken from
http://svn.freebsd.org/base/release/9.1.0/sys/ofed/include/linux/spinlock.h:
>
> static inline void
> spin_lock_init(spinlock_t *lock)
> {
>
> memset(&lock->m, 0, sizeof(lock->m));
> mtx_init(&lock->m, "lnxspin", NULL, MTX_DEF | MTX_NOWITNESS);
> }
>
> But MTX_DEF initializes mutex as a sleep mutex:
>
> By default, MTX_DEF mutexes will context switch when they are already
>
> held.
>
>
> There is a flag MTX_SPIN Which I think is the right one in this case .
>
>
>
> I'd appreciate your take on this issue.
Since FreeBSD uses a different approach to interrupt handlers (they run in threads, not in the bottom half), a regular mutex may in fact give the closest match to the same semantics. Regular mutexes are also cheaper and in general preferable to spin mutexes whenever possible.
--
John Baldwin
More information about the freebsd-arch
mailing list