Skip site navigation (1)Skip section navigation (2)
Date:      Wed, 22 May 2013 13:48:00 +0000
From:      Orit Moskovich <oritm@mellanox.com>
To:        John Baldwin <jhb@freebsd.org>
Cc:        "freebsd-arch@freebsd.org" <freebsd-arch@freebsd.org>
Subject:   RE: FreeBSD spinlock - compatibility layer
Message-ID:  <981733489AB3BD4DB24B48340F53E0A55B0D3CD8@MTLDAG01.mtl.com>
In-Reply-To: <201305220859.32948.jhb@freebsd.org>
References:  <981733489AB3BD4DB24B48340F53E0A55B0CFD79@MTLDAG01.mtl.com> <201305211220.16776.jhb@freebsd.org> <981733489AB3BD4DB24B48340F53E0A55B0D39EF@MTLDAG01.mtl.com> <201305220859.32948.jhb@freebsd.org>

next in thread | previous in thread | raw e-mail | index | archive | help
>From the mutex man page " By default, MTX_DEF mutexes will context switch w=
hen they are already held."
How is sleeping forbidden, but blocking on a mutex that might context switc=
h is ok?

-----Original Message-----
From: John Baldwin [mailto:jhb@freebsd.org]=20
Sent: Wednesday, May 22, 2013 04:06 PM
To: Orit Moskovich
Cc: freebsd-arch@freebsd.org
Subject: Re: FreeBSD spinlock - compatibility layer

On Wednesday, May 22, 2013 2:14:51 am Orit Moskovich wrote:
> From what I've read in "FreeBSD - device drivers" book by Joseph Kong=20
> on
interrupt handling, you cannot voluntarily context switch (that is, sleep) =
in interrupt threads .

That is not the same thing.  By sleep it means call a *sleep() function or =
wait on a cond var.  Not block on a mutex or rwlock.

> In any case, I think that the functionality of spin mutex should=20
> remain as
is, and not modified to sleep mutex, as it can be used in places that sleep=
 mustn't be used, or that require the properties of the spin due to perform=
ance considerations.

No, spin locks are _slower_ and reduce performance.  FreeBSD is much more l=
ike Solaris in this regard.  Spin mutexes on FreeBSD are similar to dispatc=
her locks in Solaris which 99% of the kernel should never use.

--
John Baldwin



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?981733489AB3BD4DB24B48340F53E0A55B0D3CD8>