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